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ENTITY  AUTHENTICATION 
USING  PUBLIC  KEY  CRYPTOGRAPHY 


Federal  Information  Processing  Standards  (FTPS  PUBS)  are  issued  by  the  National  Institute  of 
Standards  and  Technology  (NIST)  after  approval  by  the  Secretary  of  Commerce  pursuant  to 
Section  5131  of  die  Information  Technology  Management  Reform  Act  of  1996.  and  the  Computer 
Security  Act  of  1987,  Public  Law  104-106. 

1.  Name  of  Standard.  Entity  Authentication  Using  Public  Key  Cryptography  (FIPS  PUB 
196). 


2.  Category  of  Standard.  Computer  Security,  Subcategory  Access  Control. 

3.  Explanation.  This  standard  specifies  two  challenge-response  protocols  by  which  entities 
in  a  computer  system  may  authenticate  their  identities  to  one  another.  These  protocols  may  be 
used  during  session  initiation,  and  at  any  other  time  that  entity  authentication  is  necessary. 
Depending  on  which  protocol  is  implemented,  either  one  or  both  entities  involved  may  be 
authenticated.  The  defined  protocols  are  derived  from  an  international  standard  for  entity 
authentication  based  on  public  key  cryptography,  which  uses  digital  signatures  and  random 
number  challenges. 

Authentication  based  on  public  key  cryptography  has  an  advantage  over  many  other 
authentication  schemes  because  no  secret  information  has  to  be  shared  by  the  entities  involved 
in  die  exchange.  A  user  (claimant)  attempting  to  authenticate  oneself  must  use  a  private  key  to 
digitally  sign  a  random  number  challenge  issued  by  the  verifying  entity.  This  random  number 
is  a  time  variant  parameter  which  is  unique  to  the  authentication  exchange.  If  the  verifier  can 
successfully  verify  the  signed  response  using  the  claimant's  public  key,  then  the  claimant  has 
been  successfully  authenticated. 

4.  Approving  Authority.  Secretary  of  Commerce. 

5.  Maintenance  Agency.  Department  of  Commerce,  National  Institute  of  Standards  and 
Technology,  Information  Technology  Laboratory. 

6.  Cross  Index. 

a.  FIPS  PUB  140-1,  Security  Requirements  for  Cryptographic  Modules. 


b.  FIPS  PUB  171,  Key  Management  Using  ANSI  X9.I7. 

c.  FIPS  PUB  180-1,  Secure  Hash  Standard. 

d.  FIPS  PUB  186,  Digital  Signature  Standard. 

e.  FIPS  PUB  190,  Guideline  for  the  Use  of  Advanced  Authentication  Technoiog> 
Alternatives. 

f.  ANSI  X9. 17-1985,  Financial  Institution  Key  Management  (Wholesale). 

g.  ISO/IEC  9798-1:1991,  Information  technology  -  Security  techniques  -  Entity 
authentication  mechanisms  -  Part  1:  General  model. 

h.  ISO/IEC  9798-3:1993,  Information  technology  -  Security  techniques  -  Entity 
authentication  mechanisms  -  Part  3:  Entity  authentication  using  a  public  key 
algorithm. 

Other  NIST  publications  may  be  applicable  to  die  implementation  and  use  of  this  standard. 
A  list  (NIST  Publications  List  91)  of  currently  available  computer  security  publications, 
including  ordering  information,  can  be  obtained  from  NIST. 

7.  Applicability.  This  standard  is  applicable  to  all  Federal  departments  and  agencies  that  use 
public  key  based  authentication  systems  to  protect  unclassified  information  within  computer  and 
digital  telecommunications  systems  that  are  not  subject  to  Section  2315  of  Title  10,  U.S.  Code, 
or  Section  3502(2)  of  Title  44,  U.S.  Code.  This  standard  shall  be  used  by  all  Federal 
departments  and  agencies  in  designing,  acquiring  and  implementing  public  key  based,  challenge- 
response  authentication  systems  at  the  application  layer  within  computer  and  digital 
telecommunications  systems.  This  includes  all  systems  that  Federal  departments  and  agencies 
operate  or  that  are  operated  for  them  under  contract.  In  addition,  this  standard  may  be  used  at 
other  layers  within  computer  and  digital  telecommunications  systems. 

This  standard  may  be  adopted  and  used  by  non-Federal  Government  organizations.  Such  use  is 
encouraged  when  it  is  either  cost  effective  or  provides  interoperability  for  commercial  and  private 
organizations. 

8.  Applications.  Numerous  applications  can  benefit  from  the  incorporation  of  entity 
authentication  based  on  public  key  cryptography,  when  the  implementation  of  such  technology 
is  considered  cost-effective.  Networking  applications  that  require  remote  login  will  be  able  to 
authenticate  clients  who  have  not  previously  registered  with  the  host,  since  secret  material  (e.g., 
a  password)  does  not  have  to  be  exchanged  beforehand.  Also,  point-to-point  authentication  can 
take  place  between  users  who  are  unknown  to  one  another.  The  authentication  protocols  in  this 
standard  may  be  used  in  conjunction  with  other  public  key-based  systems  (e.g.,  a  public  key 
infrastructure  that  uses  public  key  certificates)  to  enhance  the  security  of  a  computer  system. 

9.  Specifications.  Federal  Information  Processing  Standard  (FIPS)  196,  Entity  Authentication 
Using  Public  Key  Cryptography  (affixed). 

10.  Implementations.  The  authentication  protocols  described  in  this  standard  may  be 
implemented  in  software,  firmware,  hardware,  or  any  combination  thereof. 
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11.  Export  Control,  implementations  of  this  standard  are  subject  to  Federal  Government 
export  controls  as  specified  in  Title  15,  Code  of  Federal  Regulations.  Parts  768  through  799 
Exporters  arc  advised  to  contact  the  Department  of  Commerce,  Bureau  of  Export  Administration, 
for  more  information. 

12.  Implementation  Schedule.  This  standard  becomes  effective  April  6.  1997. 

13.  Qualifications.  The  authentication  technology  described  in  this  standard  is  based  upon 
information  provided  by  sources  within  the  Federal  Government  and  private  industry. 
Authentication  systems  are  designed  to  protect  against  adversaries  (e.g.,  hackers,  organized  crime, 
economic  competitors)  mounting  cost-effective  attacks  an  unclassified  government  or  commercial 
data.  The  primary  goal  in  designing  an  effective  security  system  is  to  make  the  cost  of  any 
attack  greater  than  die  possible  payoff. 

While  specifications  in  this  standard  are  intended  to  maintain  the  security  of  an  authentication 
protocol,  conformance  to  this  standard  does  not  guarantee  that  a  particular  implementation  is 
secure.  It  is  the  responsibility  of  the  manufacturer  to  build  the  implementation  of  an 
authentication  protocol  in  a  secure  manner.  This  standard  will  be  reviewed  every  five  years  in 
order  to  assess  its  adequacy. 

14.  Waivers.  Under  certain  exceptional  circumstances,  the  heads  of  Federal  departments  and 
agencies  may  approve  waivers  to  Federal  Information  Processing  Standards  (FIPS).  The  head 
of  such  agency  may  re-delegate  such  authority  only  to  a  senior  official  designated  pursuant  to 
section  3506(b)  of  Title  44,  U.S.  Code.  Waivers  shall  be  granted  only  when: 

a.  Compliance  with  a  standard  would  adversely  affect  the  accomplishment  of  the  mission 
of  an  operator  of  a  Federal  computer  system,  or 

b.  Cause  a  major  adverse  financial  impact  on  the  operator  which  is  not  offset  by 
Government-wide  savings. 

Agency  heads  may  act  upon  a  written  waiver  request  containing  the  information  detailed 
above.  Agency  heads  may  also  act  without  a  written  waiver  request  when  they  determine  that 
conditions  for  meeting  the  standard  cannot  be  met.  Agency  heads  may  approve  waivers  only  by 
a  written  decision  which  explains  the  basis  on  which  the  agency  head  made  the  required 
finding(s).  A  copy  of  each  such  decision,  with  procurement  sensitive  classified  portions  clearly 
identified,  shall  be  sent  to:  National  Institute  of  Standards  and  Technology,  ATTN:  FIPS 
Waiver  Decisions,  Building  225,  Room  A231.  Gaithersburg,  MD  20899. 

In  addition,  notice  of  each  waiver  granted  and  each  delegation  of  authority  to  approve  waivers 
shall  be  sent  promptly  to  the  Committee  on  Government  Operations  of  the  House  of 
Representatives  and  the  Committee  on  Governmental  Affairs  of  the  Senate  and  shall  be  published 
promptly  in  the  Federal  Register. 


When  the  determination  on  a  waiver  applies  to  the  procurement  of  equipment  and/or  services, 
a  notice  of  the  waiver  determination  must  be  published  in  the  Commence  Business  Daily  as  a  pan 
of  the  notice  of  solicitation  for  offers  of  an  acquisition  or,  if  the  waiver  determination  is  made 
after  that  notice  is  published,  by  amendment  to  such  notice. 

A  copy  of  the  waiver,  any  supporting  documents,  the  document  approving  the  waiver  and  any 
supporting  and  accompanying  documents,  with  such  deletions  as  the  agency  is  authorized  and 
derides  to  make  under  5  U.S.C.  Section  552(b),  shall  be  pan  of  the  procurement  documentation 
and  retained  by  the  agency. 

15.  Where  to  Obtain  Copies.  Copies  of  this  publication  are  available  for  sale  by  the 
National  Technical  Information  Service,  U.S.  Department  of  Commerce.  Springfield.  VA  22161. 
When  ordering,  refer  to  Federal  Information  Processing  Standards  Publication  196  (FIPS  PUG 
196),  and  identify  the  title.  When  microfiche  is  desired,  this  should  be  specified.  Payment  may 
be  made  by  check,  money  order,  credit  card,  or  deposit  account 
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1.  INTRODUCTION 


This  publication  specifies  two  protocols  for  entity  authentication  that  use  a  public  ke> 
cryptographic  algorithm  for  generating  and  verifying  digital  signatures.  One  entity  can  prove  its 
identity  to  another  entity  by  using  a  private  key  to  generate  a  digital  signature  on  a  random 
challenge.  The  use  of  cryptography  provides  for  strong  authentication,  which  does  not  require 
authenticating  entities  to  share  secret  information.  Federal  government  computer  systems  which 
implement  this  standard  shall  generate  and  verify  digital  signatures  in  accordance  with  a  FIPS 
approved  public  key  digital  signature  algorithm  (e.g.,  FIPS  PUB  186,  Digital  Signature 
Standard). 

International  Standard  ISO/IEC  9798-3:1993,  Entity  authentication  using  a  public  key  algorithm 
(ISO/IEC  9798-3),  serves  as  the  basis  for  the  authentication  protocols  defined  in  Section  3  below. 
That  international  standard  defines  five  different  protocols,  addressing  both  unilateral  and  mutual 
entity  authentication,  that  make  use  of  a  public  key  cryptographic  algorithm.  In  particular,  digital 
signatures  are  used  in  determining  an  entity’s  authenticity.  Only  one  protocol  for  each  unilateral 
and  mutual  authentication  was  selected  from  ISO/IEC  9798-3.  Certain  authentication  token  fields 
and  protocol  steps  are  described  in  greater  detail  in  this  standard  than  in  ISO/IEC  9798-3. 

Although  ISO/IEC  9798-3  serves  as  die  basis  for  this  standard,  this  specification  is  less  strict,  in 
that  it  allows  for  the  arbitrary  ordering  of  token  fields.  This  allowance  therefore  enables  other 
non-ISO  public  key  authentication  protocols  to  meet  the  requirements  of  this  standard.  Those 
requirements  are  specified  in  the  following  sections. 

Section  2  of  this  standard  presents  a  general  overview  of  the  entity  authentication  protocols 
defined  herein.  It  also  (1)  highlights  the  criteria  that  must  be  met  to  conform  to  this  standard, 
(2)  briefly  describes  threats  addressed  by  using  the  authentication  protocols,  and  (3)  lists 
definitions  and  notation  used  in  this  standard.  The  authentication  protocols,  along  with  issues 
pertaining  to  authentication  token  information,  are  described  in  detail  in  Section  3.  Several 
appendices  accompanying  this  standard  describe  optional  methods  for  formatting  and  encoding 
authentication  information.  These  methods  are  included  for  informational  purposes  only,  to  help 
promote  the  interoperability  of  various  implementations  of  the  authentication  protocols  defined 
in  Section  3. 


2.  GENERAL 


2.1  Scope 

2.1.1  Implementation  Criteria 

To  acceptably  implement  this  standard,  an  implementation  must  meet  the  following  criteria: 

1)  Each  entity  in  an  authentication  exchange  must  use  a  FIPS  approved  digital  signature 
algorithm  to  generate  and/or  verify  digital  signatures; 

2)  Earfi  entity  must  generate  (pseudo)random  numbers  usmg  a  FIPS  approved  (pseudorandom 
number  generator; ' 

3)  Each  entity  acting  as  a  claimant  must  be  bound  to  a  public/private  key  pair,  the  private  key 
should  remain  in  the  sole  control  of  die  claimant  who  uses  that  key  to  sign  a  random  challenge. 
The  key  binding  requires  a  unique  authentication  identifier  for  each  claimant,  so  that  a  verifier 
can  Higtingiiish  between  multiple  claimants;  and 

4)  One  or  both  of  the  authentication  protocols  in  this  standard  must  be  implemented.  For  each 
protocol,  steps  and  token  fields  marked  as  [OPTIONAL]  do  not  need  to  be  implemented,  except 
where  indicated  otherwise.  However,  all  other  steps  and  token  fields  must  be  implemented. 

2.1.2  Overview 

Entity  authentication  protocols  in  this  standard  make  use  of  a  digital  signature  algorithm  for  the 
generation  of  authentication  tokens.  The  authentication  protocols  are  independent  of  the  nature 
of  the  authenticating  entities  (e.g.,  for  mutual  authentication,  the  same  protocol  is  used  for 
human-human,  human-process,  and  process-process  authentication).  In  situations  where  a  human 
is  involved  as  a  principal,  a  two-step  sequence  usually  takes  place,  due  to  the  complexity  of 
cryptography.  A  human  user  first  authenticates  oneself  to  a  cryptographic  module,  which  then 
acts  as  a  claimant  and  performs  the  actual  signature  generation  and/or  verification  on  behalf  of 
the  human  user  (see  Section  3.1.1). 

The  authentication  of  an  entity  (viz.,  a  claimant  to  a  verifier)  depends  on  two  successful  actions: 
(1)  the  verification  of  the  claimant's  binding  with  its  public/private  key  pair,  and  (2)  the 
verification  of  the  claimant's  digital  signature  on  a  random  number  challenge.  A  binding  of  an 
entity's  unique  identifier  with  its  key  pair  is  essential  to  proving  the  authenticity  of  that  entity's 
identity.  This  must  be  done  prior  to  any  authentication  exchange.  During  an  authentication 
exchange,  a  random  number  challenge  generated  by  the  verifier  is  associated  with  the  claimant's 
identifier.  The  claimant  then  generates  a  signature  on  that  challenge,  which  is  freshly  generated 
for  that  particular  exchange.  In  order  to  verify  a  signature,  the  verifier  uses  the  claimant's 
identifier  to  find  a  public  key  that  is  bound  to  that  identifier.  If  that  public  key  can  be  used  to 
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successfully  verify  the  claimants  signature  on  the  challenge,  then  the  verifier  has  m  fact  verified 
that  the  claimant  is  the  same  entity  that  is  bound  to  the  key  pair.  This  chain  of  associations, 
bindings,  and  signatures  is  what  allows  an  entity  to  successfully  authenticate  itself  The  next 
several  paragraphs  address  some  issues  of  entity-key  bindings,  random  challenges,  and  identifiers 

Public  key  certificates  are  not  required  by  this  standard,  and  the  utilizanon  of  a  public  kev 
infrastructure  lies  outside  die  scope  of  this  standard.  Whether  or  not  public  key  certificates  are 
used  in  an  authentication  implementation,  each  public/private  key  pair  shall  be  bound  to  a 
particular  entity.  Such  a  binding  may  be  performed  by  a  verifier  or  a  third  party  that  is  trusted 
by  die  verifier.  Trusted  third  parties  may  be  used  in  conjunction  with  this  standard  to  distribute 
delegation  keys,  login  tickets,  public  keys,  or  public  key  certificates.  Delegauon  keys  are  keys 
issued  by  one  entity  to  let  another  entity  act  upon  die  issuer's  behalf;  login  uckets  are  generated 
by  a  third  party,  and  used  by  one  entity  to  authenticate  to  another.  Neither  of  these  items  is  used 
in  this  standard,  but  may  be  included  in  a  particular  implementation  using  the  optional  text  fields 
provided  in  the  exchanged  authentication  tokens  (see  Section  3.13).  Trusted  third  parties  may 
provide  other  necessary  services,  such  as  a  courier  service  to  transport  valid  public  keys. 

Since  the  protocols  defined  in  this  standard  utilize  (pseudo)random  number  values  for  the 
authentication  tokens'  time  variant  parameters,  authenticating  endties  do  not  have  to  use 
synchronized  clocks  to  verify  the  freshness  and  timeliness  of  authentication  tokens.  (Note: 
Throughout  the  rest  of  this  document,  the  term  ''random"  number  will  imply  the  use  of  either  a 
random  or  pseudorandom  number.)  Authentication  exchanges  using  date-time  stamps  and 
sequence  numbers  were  not  chosen  for  this  standard  due  to  their  requirements  of  maintaining 
synchronized  clocks  and  sequence  number  log  tables,  respectively.  Random  number  challenges 
are  generally  easier  to  use  in  widely  distributed  environments  where  entities  do  not  necessarily 
know  one  another  prior  to  authentication. 

A  naming  convention  for  the  entities  involved  in  an  authentication  exchange  is  not  defined  in  this 
standard.  However,  unique,  distinguishing  identifiers  for  participating  authenticauon  entities 
should  be  established  prior  to  the  execution  of  either  of  those  protocols.  Each  entity  being 
authenticated  must  have  such  an  identifier,  which  can  be  used  to  uniquely  associate  it  with  a 
public/private  key  pair. 

Biometric  authentication  techniques  are  not  included  in  the  authentication  exchanges  in  Section 
3.  Information  pertaining  to  biometrics,  or  the  results  of  performing  a  biometric  live  scan,  may 
be  included  in  an  authentication  token  s  optional  text  field,  and  that  data  may  be  used  in 
determining  authentication  success  or  failure.  However,  the  lack  of  that  biometric  functionality, 
in  an  implementation  of  either  protocol,  will  noi  prevent  that  implementation  from  meeting  the 
requirements  of  this  standard. 

Upon  completion  of  either  of  the  entity  authentication  protocols  in  this  standard,  the  entity 
performing  the  final  verification  step  may  send  an  acknowledgement  of  verification  success  or 
failure  to  the  other  entity  involved  in  the  exchange.  Although  the  format  and  use  of  such  an 


acknowledgment  is  not  within  the  scope  of  this  standard,  in  certain  implementations  it  mav  be 
necessary  to  inform  the  other  principal  of  a(n)  (im)successful  authentication  exchange. 

12  Threats 

The  protocols  defined  in  this  document  address  several  threats,  including  masquerade,  password 
compromise,  replay  attacks,  and  die  signing  of  pie-defined  data.  Using  challenges  and  digital 
signatures  eliminates  the  need  for  transmitting  passwords  for  authentication,  which  reduces  the 
threat  of  their  compromise.  Such  a  compromise  would  allow  an  attacker  to  use  the  same 
information  to  authenticate  repeatedly.'  By  using  a  private  key  to  generate  digital  signatures  for 
authentication,  it  becomes  computationally  infeasible  for  an  attacker  to  masquerade  as  another 
entity.  However,  implementations  may  still  rely  on  passwords  for  an  entity  to  access  its  private 
key.  In  that  case,  passwords  must  be  kept  secure.  Although  the  use  of  public  key  cryptography 
eliminates  die  need  for  entities  to  share  a  secret  value,  it  is  extremely  important  that  each 
claimant  always  keeps  its  private  key  secure,  and  under  its  sole  control. 

The  use  of  random  number  challenges  also  prevents  an  intruder  from  copying  an  authentication 
token  signed  by  another  user  and  replaying  it  successfully  at  a  later  time.  However,  a  new 
random  number  challenge  should  be  generated  for  each  authentication  exchange.  The  security 
of  replay  prevention  also  hinges  on  the  generation  of  random  number  challenges  which  have  a 
low  probability  of  being  repeated. 

Finally,  by  including  a  random  number  of  its  own  in  an  authentication  token,  a  claimant  can 
preclude  die  signing  of  only  data  that  is  pre-defined  by  die  verifier.  If  a  claimant  uses  a  private 
key  for  more  than  just  signing  authentication  tokens,  for  example,  then  a  verifier  could 
maliciously  create  a  challenge  consisting  of  information  which  is  meaningful  in  another  context. 
This  can  be  prevented  when  the  claimant  signs  both  the  challenge  and  unpredictable,  meaningless 
data  -  a  random  number.  This  is  why  the  responder  in  the  mutual  authentication  protocol 
generates  a  signature  over  both  random  numbers,  instead  of  just  signing  the  initiator's  random 
number  challenge. 

The  authentication  protocols  in  Section  3  do  not  address  other  threats,  which  include  denial  of 
service,  session  capture,  transmission  modification,  and  the  use  of  another  entity's  compromised 
private  key.  No  aspect  of  the  authentication  tokens  or  protocols  preclude  another  entity  from 
rerouting  or  modifying  authentication  transmissions.  Maintaining  the  secrecy  of  one's  private  key 
is  of  utmost  importance,  and  failure  to  do  so  may  result  in  one  entity  masquerading  as  another 
entity  by  using  the  latter's  private  key  for  authentication.  Other  security  measures,  which  lie 
outside  the  scope  of  this  standard,  may  be  needed  in  order  to  address  such  additional  threats  and 
vulnerabilities. 
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23  Definitions  and  notation 


2.3.1  Definitions 

Some  of  the  following  definitions  are  taken  from  terminology  defined  in  ISO/IEC  979S-1 :  ]OQi . 
General  Model  (ISO/EC  9798-1)  which  describes  the  general  model  for  the  ISO/IEC  9798  senes 
of  entity  authentication  standards.  Other  definitions  are  from  FIPS  PUB  140-1.  Section  2.1. 

Authentication  token  (viz.,  token):  authentication  information  conveyed  during  an  authentication 
exchange. 

Binding:  an  acknowledgement  by  a  trusted  third  party  that  associates  an  entity's  identity  with  its 
public  key.  This  may  take  place  through  (1)  a  certification  authority’s  generation  of  a  public  key 
certificate,  (2)  a  security  officer’s  verification  of  an  entity’s  credentials  and  placement  of  the 
entity’s  public  key  and  identifier  in  a  secure  database,  or  (3)  an  analogous  method. 

Claimant  an  entity  which  is  or  represents  a  principal  for  the  purposes  of  authentication,  together 
with  the  functions  involved  in  an  authentication  exchange  on  behalf  of  that  entity.  A  claimant 
acting  on  behalf  of  a  principal  must  include  the  functions  necessary  for  engaging  in  an 
authentication  exchange,  (e.g.,  a  smartcard  (claimant)  can  act  on  behalf  of  a  human  user 
(principal) ) 

Cryptographic  module:  die  set  of  hardware,  software,  firmware,  or  some  combination  thereof 
that  implements  cryptographic  logic  or  processes,  including  cryptographic  algorithms,  and  is 
contained  within  the  cryptographic  boundary  of  the  module.  (See  FTPS  PUB  140-1) 

Digital  signature  (viz.,  signature):  a  nonforgeable  transformation  of  data  that  allows  the  proof 
of  the  source  (with  nonrepudiation)  and  the  verification  of  the  integrity  of  that  data. 

Distinguishing  identifier,  information  which  unambiguously  distinguishes  an  entity  in  the 
authentication  process. 

Entity:  any  participant  in  an  authentication  exchange;  such  a  participant  may  be  human  or  non¬ 
human,  and  may  take  the  role  of  a  claimant  and/or  verifier. 

FIPS  approved  security  method:  a  security  method  (e.g.,  cryptographic  algorithm,  cryptographic 
key  generation  algorithm  or  key  distribution  technique,  random  number  generator,  authentication 
technique,  or  evaluation  criteria)  that  is  either  a)  specified  in  a  FIPS,  or  b)  adopted  in  a  FIPS  and 
specified  either  in  an  appendix  to  the  FIPS  or  in  a  document  referenced  by  the  FIPS. 

Initiator,  the  entity  that  initiates  an  authentication  exchange. 

Principal:  an  entity  whose  identity  can  be  authenticated. 
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Private  key.  a  cryptographic  key  used  with  a  public  key  cryptographic  algorithm,  which  is 
uniquely  associated  with  an  entity,  and  not  made  public;  h  is  used  to  generate  a  digital  signaiurt: 
this  key  is  mathematically  linked  with  a  corresponding  public  key. 

Public  key.  a  cryptographic  key  used  with  a  public  key  cryptographic  algorithm  uniquely 
associated  with  an  entity,  and  which  may  be  marie  public;  it  is  used  to  verify  a  digital  signature: 
this  key  is  mathematically  linked  with  a  corresponding  private  key. 

Public  key  certificate  (certificate):  a  set  of  data  that  unambiguously  identifies  an  entity,  contains 
the  entity's  public  key,  and  is  digitally  signed  by  a  trusted  third  party  (certification  authority). 

Public  key  infrastructure  (PK1):  an  architecture  which  is  used  to  bind  public  keys  to  entities, 
enable  other  entities  to  verify  public  key  bindings,  revoke  such  bindings,  and  provide  other 
services  critical  to  managing  public  keys. 

Responder,  the  entity  that  responds  to  the  initiator  of  the  authentication  exchange. 

Signed  data:  data  on  which  a  digital  signature  is  generated. 

Unsigned  data:  data  included  in  an  authentication  token,  in  addition  to  a  digital  signature.  An 
exception  to  this  is  TokenBA,  in  each  authentication  exchange,  which  contains  only  unsigned 
data  and  no  signature.  Unsigned  data  gives  information  to  the  token  recipient  which  may  be  used 
to  verify  the  token's  signature  and/or  generate  a  response  token.  This  unsigned  data  may  be 
equivalent  to  the  signed  data,  but  not  necessarily. 

Verifier,  an  entity  which  is  or  represents  the  entity  requiring  an  authenticated  identity.  A  verifier 
includes  the  functions  necessary  for  engaging  in  authentication  exchanges. 

2.3.2  Notation 

In  Section  3,  the  following  notation  is  used  in  describing  parts  of  the  authentication  exchanges. 
Most  of  this  notation  is  used  in  ISO/IEC  9798-3. 

A  -  the  distinguishing  identifier  (name)  of  entity  A. 

B  -  the  distinguishing  identifier  (name)  of  entity  B. 

Sx  -  a  private  key  associated  with  entity  X.  used  in  generating  a  digital  signature. 

Rx  -  a  random  number  issued  by  entity  X. 

X  ||  Y  -  the  result  of  the  concatenation  of  data  items  X  and  Y,  not  necessarily  in  that  order. 
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CertX  -  a  trusted  third  party's  certificate  for  entity  X.  that  binds  X  with  a  public-private  key 
pair,  may  also  indicate  a  chain  of  certificates  beginning  or  ending  with  CertX. 

TextN  -  data  of  unspecified  format  or  length  that  may  be  included  m  a  token. 

TokenID  -  token  identifier  -  information  accompanying  an  authentication  token  that  may  oe 
used  to  identify  the  token  and/or  protocol  type  to  assist  token  processing  by  the 
recipient 

TokenXY  -  a  token  sent  from  entity  X  to  entity  Y. 

TokenXY,  -  the  i*  token  sent  from  entity  X  to  entity  Y. 

sSx(Z)  -  die  digital  signature  of  data  Z  using  the  private  key  S*  Z  is  referred  to  as  "signed 
data". 

[  Z  ]  -  indicates  that  item  Z  is  an  optional  element 

[OPTIONAL]  -  indicates  that  die  accompanying  step  is  optional:  it  does  not  have  to  be 

executed  in  order  for  the  implementation  to  conform  to  this  standard. 
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3.  ENTITY  AUTHENTICATION  PROTOCOLS 


3.1  Authentication  protocol  issues 

Certain  factors  should  be  considered  before  initiating  either  of  the  authentication  protocols 
described  in  this  standard. 

3.1.1  Digital  signatures 

Each  entity  involved  in  an  authentication  protocol  in  Section  3  must  have  the  ability  to  generate 
and/or  verify  a  digital  signature.  Entities  acting  as  claimants  must  have  a  digital  signature 
generation  capability,  and  verifiers  must  have  a  digital  signature  verification  capability ■.  A  FIPS 
approved  public  key  digital  signature  algorithm  (e.g^  FIPS  PUB  186,  Digital  Signature  Standard 
(DSS)  )  must  be  implemented  to  provide  these  digital  signature  functions. 

A  public/private  key  pair  compliant  with  die  digital  signature  algorithm  must  be  possessed  by 
each  claimant  It  is  critical  to  the  security  of  the  authentication  exchanges  that  a  private  ke y 
remain  accessible  to  only  one  claimant.  The  entity  authentication  implementation  shall  employ 
an  identity-based  operator  authentication  mechanism  "in  order  to  verify  the  authorization  of  the 
operator  to  assume  the  desired  roles  and  to  request  corresponding  services"  (FIPS  PUB  140-1, 
Security  Requirements  for  Cryptographic  Modules).  This  establishes  a  one-to-one  relationship 
between  an  entity  and  the  private  (signing)  key,  and  it  also  helps  prevent  unauthorized  entities 
from  authenticating  themselves  falsely  using  the  key  material. 

3.1.2  Random  numbers 

To  create  random  numbers  for  the  two  authentication  exchanges  described  in  this  standard,  only 
FIPS  approved  random  number  generators  shall  be  used.  At  a  minimum,  these  include  generators 
found  in: 

-Appendix  3  of  FIPS  PUB  1 86.  and 

-Appendix  C  of  ANSI  X9. 17-1985.  Financial  Institution  Key  Management  (Wholesale). 

In  the  authentication  exchanges  described  in  Sections  3.2  and  3.3,  the  verifier  uses  a  random 
number  as  a  challenge  to  the  claimant,  and  the  claimant  uses  a  random  number  to  preclude 
signing  only  data  determined  by  the  verifier  (see  Section  22  for  a  discussion  of  potential  threats). 

An  implementor  may  choose  to  use  other  types  of  time  variant  parameters  in  the  authentication 
exchanges  in  this  standard,  however  they  shall  be  used  in  conjunction  with  the  random  number 
challenge,  which  remains  the  basis  for  verifying  an  entity’s  authenticity.  One  possible  approach 
is  to  combine  (e.g.,  exclusive-OR.  concatenate,  etc.)  a  non-repeating  sequence  number  with  the 
output  of  the  random  number  generator,  and  using  the  result  as  the  random  number  challenge. 

It  is  important  to  note  that  each  entity  that  acts  as  a  verifier  must  maintain  state,  because 
knowledge  of  the  original  random  number  challenge  is  essential  when  the  verifier  attempts  to 
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verify  the  claimant's  response.  To  maintain  state  for  the  duration  of  an  authentication  exchange, 
a  verifier  must  keep  a  record  of  both  (1)  a  freshly  generated  random  number  challenge  and  (2) 
an  association  between  that  challenge  and  the  claimant.  Linking  the  claimant  to  the  appropriate 
random  number  challenge  is  especially  important  when  the  verifier  is  involved  in  several 
simultaneous  authentication  sessions.  How  this  is  done  depends  on  the  particular  implementation 
In  some  implementations,  it  may  be  necessary  to  link  the  random  number  with  the  claimant  using 
the  optional  TokenED  field  which  may  be  sent  with  a  token. 

3.1.3  Identifiers 

Unique,  distinguishing  identifiers  shall  be  determined  for  all  entities  which  have  the  potential  for 
communicating  with  one  another,  before  the  authentication  protocol  is  mitiated.  A  naming 
convention  shall  be  established  such  that  a  verifier  can  differentiate  between  all  entities  which 
act  as  claimants,  and  each  claimant  has  a  unique  identifier  for  each  verifier.  If  certificates  are 
used,  the  naming  convention  used  in  identifying  entities  to  one  another  during  the  authentication 
exchange  does  not  have  to  be  the  same  as  the  certificate  naming  convention.  However,  each 
entity  must  have  some  means  of  correlating  a  name  in  a  certificate  with  the  identifier  used  during 
authentication. 

In  the  entity  authentication  protocols  below,  a  token  identifier  (TokenID)  may  be  mcluded  with 
each  token  transmission.  Such  an  identifier  might  indicate  the  type  of  token  being  sent,  and  the 
authentication  exchange  to  which  it  belongs.  The  format  for  these  token  identifiers  is  outside  the 
scope  of  this  standard. 

3.1.4  Public  key  certificates 

If  public  key  certificates  are  used  in  die  authentication  process,  then  they  must  be  generated  prior 
to  the  authentication  exchange,  and  should  be  maintained  so  that  they  are  readily  accessible  to 
any  entity  that  wishes  to  authenticate  another  entity’s  identity.  Typically,  a  certificate  is 
generated  by  a  trusted  third  party  and  then  either  distributed  or  stored  where  prospective 
authenticating  entities  have  access  to  it.  When  an  entity  wishes  to  obtain  a  certificate  for 
verification  purposes,  the  certificate  may  he  retrieved  from  a  directory  service,  a  local  cache,  or 
an  authentication  message.  If  certificates  are  retrieved  from  a  directory  service  or  a  local  cache, 
it  is  most  expedient  to  do  this  pnor  to  the  authentication  exchange.  During  an  authentication 
exchange,  the  entity  generating  the  token  may  send  its  certificate  or  a  chain  of  certificates  with 
the  token.  Certificate  formats  are  outside  the  scope  of  this  standard,  but  particular  formats  may 
be  recommended  or  mandated  by  other  FIPS.  NIST  Special  Publications,  or  other  Federal 
regulations. 

The  manner  in  which  a  certificate  or  certificate  chain  is  verified  depends  on  die  configuration  of 
the  public  key  infrastructure  in  use.  Generally  speaking,  however,  to  verify  the  binding  between 
the  claimant  and  its  public  key,  a  verifier  must  have  a  chain  of  valid,  verifiable  certificates  -  from 
the  claimant's  certificate  to  a  certificate  issued  by  a  misted  third  party  whose  public  key  is  known 
to  the  verifier.  The  manner  in  which  the  certificate  chain  is  retrieved  is  outside  the  scope  of  this 
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standard.  Failure  of  any  verification  in  die  certificate  chain  shall  result  in  a  failure  to  verify  the 
signature  on  the  claimant's  certificate. 

If  rnrifira***  are  not  used,  then  die  claimant  must  be  bound  to  its  public/private  key  pair  in  some 
other  manner.  The  claimant's  public  key  and  any  global  variables  necessary  for  signature 
verification  may  be  exchanged  prior  to  initiating  die  authentication  exchange.  A  trusted  third 
party  may  be  used  by  a  verifier  to  obtain  a  claimant's  public  key.  Each  entity  which  performs 
authentication  verifications  may  choose  to  maintain  a  public  key  database.  The  method  by  w  hich 
these  tasks  are  accomplished  is  outside  the  scope  of  this  standard. 

3.1.5  Optional  fields  and  steps 

Farh  of  the  messages  exchanged  in  die  authentication  protocols  include  fields  that  are  marked 
"[OPTIONAL]",  as  are  some  steps  in  die  protocols.  Neither  those  fields  nor  steps  have  to  be 
implemented  in  order  to  conform  to  this  standard,  unless  indicated  otherwise.  The  authentication 
of  riaimant  docs  not  depend  on  die  use  of  any  optional  fields  or  steps.  It  is  lefi  up  to  the 
implementor  to  determine  which  optional  fields  and  steps  will  be  implemented,  and  how  they  will 
be  used. 

Farh  of  the  tokens  exchanged  in  both  die  unilateral  and  mutual  protocols  contain  generic  "Text" 
fields.  These  fields  are  optional  and  have  a  format  which  is  implementation-specific.  The 
optional  text  field  in  authentication  token  represents  an  aggregation  of  optional  fields,  which 
can  appear  in  any  order  throughout  the  token. 

Each  authentication  token  includes  an  optional  text  field(s)  containing  data  that  does  not  have  to 
be  signed.  Note  that  data  integrity  is  not  guaranteed  for  information  which  is  included  in  the 
unsigned  portion  of  a  token  but  which  is  not  digitally  signed  (i.e.,  unsigned  data  that  is  not 
included  in  the  signed  data).  It  is  recommended,  but  not  required,  that  a  signature  be  generated 
over  all  information  included  in  a  token.  The  type  of  data  that  may  be  included  is  determined 
by  the  implementor,  and  is  not  limited  by  the  specifications  in  this  standard.  The  number  of 
different  types  of  data  in  each  optional  field  is  not  limited,  either.  Use  of  the  text  fields  should 
be  carefully  implemented,  because  their  use  may  -  depending  on  the  implementation  -  create 
vulnerabilities  in  the  authentication  exchange.  Some  possible  uses  of  the  text  fields  are  listed 
below: 

Identifiers  -  An  entity  may  choose  to  include  an  identifier  for  itself  in  the  text  field  of  a  token. 
If  certificates  are  not  used  to  distribute  a  claimant's  public  key,  then  the  implementation  may 
require  that  the  claimant  include  information  identifying  itself  in  the  authentication  token. 

Time  value  -  Another  time  variant  parameter  may  be  included  in  a  token's  text  field,  in  addition 
to  the  random  challenges  that  are  used  to  determine  the  authenticity  of  entities.  However,  this 
additional  value  shall  not  replace  the  random  number  value  as  the  verifier's  challenge  to  the 
claimant.  For  example,  a  time  value  may  be  included  in  a  token  for  access  control  auditing,  if 
tokens  are  logged  by  a  verifier  upon  successful  completion  of  an  authentication  exchange. 


pr  change  data  -  Text  fields  may  include  information  used  to  distribute  a  cryptographic  kev 
(or  keys).  For  example,  an  encrypted  session  key,  or  information  used  in  establishing  a  session 
key  may  be  included  in  the  text  field.  How  the  key  distribution  is  performed  is  not  specified  in 
or  required  by  this  standard.  When  either  of  the  protocols  in  this  standard  is  used  to  establish 
a  key,  that  key  shall  not  be  used  until  each  claimant  in  the  exchange  has  been  successful!) 
authenticated. 

Biometric  data  >  An  implementation  in  addition  to  requiring  a  verifiable  response  to  a  random 
challenge,  may  optionally  include  biometric  authentication  data  to  determine  an  entity's 
authenticity.  This  is  a  physical  characteristic  of  a  claimant  (or  the  principal  on  whose  behalf  the 
claimant  is  acting),  which  is  an  additional  factor  of  authentication.  See  FIPS  PUB  1 90.  Guideline 
for  the  Use  of  Advanced  Authentication  Technology  Alternatives ,  for  more  information. 

3.1.6  Authentication  token  encoding  methods 

Descriptions  of  the  authentication  protocols  in  Sections  32  and  3.3  specify  the  contents  of 
authentication  tokens  and  steps  for  token  generation  and  verification.  However,  the  formatting 
and  encoding  of  these  tokens  is  not  specified  in  this  standard,  and  they  are  left  to  the  discretion 
of  the  implementor.  The  interoperability  of  different  implementations  of  the  authentication 
protocols  will  rely,  to  some  extent,  on  how  tokens  and  messages  are  formatted  and  encoded. 
This  is  especially  important  since  token  fields  are  ordered  arbitrarily,  and  the  format  and  content 
of  optional  text  fields  are  not  specified.  To  provide  some  implementation  guidance,  several 
informative  appendices  (A,  B,  C,  and  D)  are  provided  in  this  standard  which  specify  optional 
examples  of  formatting  and  encoding  methods.  The  implementation  of  any  one  of  those  methods 
is  not  required  for  meeting  the  specifications  of  this  standard. 
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3 2  Unilateral  authentication  protocol 


The  following  unilateral  entity  authentication  protocol  is  based  on  Section  5.1.2.  "Two  pass 
authentication",  of  ISO/IEC  9798-3.  Certain  authentication  token  fields  and  protocol  steps  are 
specified  in  greater  detail  in  this  section  than  in  ISO/IEC  9798-3.  The  verifier  may  choose  to 
terminate  the  authentication  exchange  at  my  time.  Figure  1  illustrates  this  exchange. 

The  unilateral  authentication  protocol  begins  with  die  verifier  (B)  challenging  die  claimant  (A). 
The  description  below  allows  for  situations  where  the  claimant  may  be  the  initiator  of  the 
exchange,  depending  on  the  application  of  this  protocol. 

It  is  important  to  note  that  die  success  of  an  entity's  authentication,  according  to  this  standard, 
is  not  dependent  on  die  information  contained  in  the  text  fields.  As  described  in  Secnon  2.1.  the 
authentication  of  an  entity  depends  on  two  things;  (1)  die  verification  of  the  claimants  binding 
with  its  key  pair,  and  (2)  the  verification  of  the  claimant's  digital  signature  on  the  random  number 
challenge.  How  text  field  information  is  used  is  beyond  die  scope  of  this  standard. 


Figure  1  Unilateral  Authentication  Protocol 


Unilateral  entity  authentication  occurs  as  follows: 


1)  [OPTIONAL]  The  claimant.  A,  selects  the  verifier,  B,  to  which  it  will  authenticate,  and 

makes  an  authentication  request  to  B  -  the  format  of  this  request  is  not  defined  in  this 

standard. 

2)  The  verifier,  B,  determines  if  it  will  continue,  initiate,  or  terminate  the  authentication 

exchange.  If  it  attempts  to  authenticate  the  claimant,  the  verifier  then 

a)  generates  a  random  number  challenge,  which  is  the  value  for  the  RB  field  in 
TokenBA,  below,  and  retains  this  value. 

b)  [OPTIONAL]  generates  and/or  selects  other  data  which  is  to  be  included  in  the  Textl 
field  of  TokenBA,. 

The  verifier  creates  a  challenge  token  of  the  following  form: 

TokenBA,  ■  Rb  ||  [Textl] 

Entity  B  sends  a  message  consisting  of  TokenBA,  and  an  optional  TokcnID  to  the  claimant. 

The  message  from  the  verifier  to  the  claimant  is  of  the  form: 

[TokenID]  ||  TokenBA, 

3)  Upon  receiving  the  message  including  TokenBA,,  the  claimant.  A, 

a)  [OPTIONAL]  uses  TokenID  to  determine  which  token  is  being  received. 

b)  [OPTIONAL]  retrieves  information  from  the  Textl  field,  using  it  in  a  manner  which 
is  outside  the  scope  of  this  standard. 

c)  generates  a  random  number  challenge,  which  is  the  value  for  the  RA  field  in  TokenAB 
below. 

d)  [OPTIONAL]  selects  an  identifier  for  the  verifier,  and  includes  that  in  the  B  field  of 
TokenAB. 

e)  [OPTIONAL]  generates  and/or  selects  other  data  which  is  to  be  included  in  the  Text2 
and  Text3  fields.  In  TokenAB,  Text2  is  a  subset  of  the  Text3  field,  including  cases 
where  Text2  is  the  NULL  set,  and  where  Text2  equals  Text3. 


The  claimant  creates  an  authentication  token,  TokenAB,  by  concatenating  data  and 
generating  a  digital  signature: 

TokenAB  -  R*  ||  [RJ  II  [B]  ||  [Text3]  ||  sSA(RA  ||  R*  ||  [B]  ||  [Text2]) 

The  signed  data  that  are  marked  as  optional  are  present  only  when  their  correspondme 
values  are  present  in  the  unsigned  part  of  TokenAB.  Although  RB  does  not  have  to  be  in 
the  unsigned  data  of  TokenAB,  it  must  be  included  in  the  signed  data. 

In  addition  to  con  taming  TokenAB,  the  message  may  optionally  include  a  token  identifier. 
TokenID,  and  the  claimant's  certificate  (or  chain  of  certificates),  CertA.  The  message  from 
the  claimant  to  the  verifier  is  of  die  form: 

[TokenID]  ||  [  CertA  ]  ||  TokenAB 

4)  Upon  receiving  the  message  including  TokenAB,  die  verifier,  B, 

a)  [OPTIONAL]  uses  TokenID  to  determine  which  token  is  being  received. 

b)  verifies  that  the  value  of  RB  is  the  same  as  the  value  retained  in  step  2)a),  given  that 
Rb  is  present  in  the  unsigned  part  of  TokenAB.  If  this  value  is  not  present,  then  the 
value  retained  in  step  2)a)  is  used  in  the  signature  verification  process  in  step  4)e). 

c)  verifies  that  the  identifier  for  the  claimant  has  been  obtained  in  one  of  three  ways: 
in  CertA,  TokenAB,  or  the  authentication  request  in  step  1),  depending  on  which 
optional  informadon  has  been  included.  In  the  event  that  certificates  are  not  used  for 
signature  verification,  then  the  identifier  for  entity  A  should  be  used  to  retrieve  the 
claimant's  public  key  in  some  unspecified  manner,  continue  with  step  4)e). 

d)  verifies  the  claimant's  certificate  or  certificate  chain,  assuming  certificates  are  used 
(see  Section  3.1.4). 

e)  verifies  the  claimant's  signature  m  TokenAB. 

f)  [OPTIONAL]  retrieves  data  from  the  B.  Text2,  and  Text3  fields,  using  them  in  a 
manner  which  is  outside  the  scope  of  this  standard. 

Successful  completion  of  parts  b)  through  e)  in  step  4)  means  that  the  claimant.  A,  has 
authenticated  itself  to  the  verifier,  B.  If  any  of  the  verifications  in  parts  b)  through  e) 
fail,  then  the  authentication  exchange  is  terminated.  If  certain  conditions  either  are  or  are 
not  met  in  the  optional  parts  a)  and  f),  the  verifier  may  choose  to  terminate  the 
authentication  exchange;  these  conditions  are  implementation-specific,  and  outside  the  scope 
of  this  standard. 
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3 3  Mutual  authentication  protocol 


The  following  mutual  entity  authentication  protocol  is  based  on  Section  522.  "Three  pass 
authentication",  of  ISO/IEC  9798-3.  Certain  authentication  token  fields  and  protocol  steps  are 
specified  in  greater  detail  in  this  section  than  in  ISO/IEC  9798-3.  Either  entity  may  choose  to 
terminate  the  authentication  exchange  at  any  time.  Figure  2  illustrates  this  exchange 

The  authentication  protocol  refers  to  entities  A  and  B  as  "initiator"  and  "responder".  This 

differs  from  terminology  used  to  describe  unilateral  authentication  in  Section  3.2.  because  each 
entity  acts  as  both  a  claimant  and  a  verifier  in  die  protocol  below. 

It  is  important  to  note  that  the  success  of  an  entity's  authentication,  according  to  this  standard, 
is  not  dependent  on  die  information  contained  in  the  text  fields.  As  described  in  Section  2.1.  the 
authentication  of  an  entity  depends  on  two  things:  (1)  the  verification  of  the  claimant's  binding 
with  its  key  pair,  and  (2)  the  verification  of  the  claimant's  digital  signature  on  the  random  number 
challenge.  How  text  field  information  is  used  once  an  entity's  authenticity  is  verified  is  beyond 
the  scope  of  this  standard. 
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Mutual  entity  authentication  occurs  as  follows: 

t 

1)  [OPTIONAL]  The  initiator,  A,  selects  the  responder,  B,  with  which  it  will  mutually 

authenticate,  and  makes  an  authentication  request  to  B  -  the  format  of  this  request  is  not 

defined  in  this  standard. 

2)  The  responder,  B,  determines  if  it  will  continue,  initiate,  or  terminate  the  authentication 

exchange.  If  it  attempts  to  authenticate  die  initiator,  die  responder  then 

a)  generates  a  random  number  challenge,  which  is  die  value  for  the  RB  field  in 
TokenBA,  below,  and  retains  this  value. 

b)  [OPTIONAL]  generates  and/or  selects  other  data  which  is  to  be  included  in  the  Textl 
field  of  TokenBA,. 

The  responder  creates  a  challenge  token  of  the  following  form: 

TokenBA,  ■  Rb  II  [Textl] 

Entity  B  sends  a  message  consisting  of  TokenBA,  and  an  optional  TokenID  to  die  initiator. 

The  message  from  the  responder  to  the  initiator  is  of  die  form: 

[TokenID]  ||  TokenBA, 

3)  Upon  receiving  the  message  including  TokenBA,,  die  initiator.  A, 

a)  [OPTIONAL]  uses  TokenID  to  determine  which  token  is  being  received. 

b)  [OPTIONAL]  retrieves  information  from  the  Textl  field,  using  it  in  a  manner  which 
is  outside  the  scope  of  this  standard. 

c)  generates  a  random  number  challenge  which  is  the  value  for  the  RA  field  in  TokenAB 
below;  the  value  of  RA  is  retained  by  the  initiator. 

d)  [OPTIONAL]  selects  an  identifier  for  the  responder,  and  includes  that  in  the  B  field 
of  TokenAB. 

e)  [OPTIONAL]  generates  and/or  selects  other  data  which  is  to  be  included  in  the  Text2 
and  Text3  fields.  In  TokenAB,  Text2  is  a  subset  of  the  Text3  field,  including  cases 
where  Text2  is  the  NULL  set,  and  where  Text2  equals  Text3. 
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The  initiator  creates  an  authentication  token,  TokenAB,  by  concatenating  data  and 
generating  a  digital  signature: 

TokenAB  -  RA  ||  [R  J  ||  [B]  ||  [T«t3]  ||  sS  j|  R  Jl  fB]  ||  rText2]) 

The  signed  data  that  are  marked  as  optional  are  present  only  when  their  corresponding 
values  are  present  in  the  unsigned  part  of  TokenAB.  Although  RB  does  not  have  to  be  in 
the  unsigned  data  of  TokenAB,  it  must  be  included  in  the  signed  data  (see  Section  2.2) 

In  addition  to  containing  TokenAB,  the  message  may  optionally  include  a  token  identifier. 
TokenID,  and  die  initiator's  certificate  (or  chain  of  certificates),  CertA.  The  message  from 
the  initiator  to  die  responder  is  of  the  form: 

[TokenID]  ||  [  CertA  ]  ||  TokenAB 
4)  Upon  receiving  the  TokenAB  transmission,  the  responder,  B, 

a)  [OPTIONAL]  uses  TokenID  to  determine  which  token  is  being  received. 

b)  verifies  that  the  value  of  Rg  is  die  same  as  the  value  retained  in  step  2)a),  given  that 
Rb  is  present  in  die  unsigned  part  of  TokenAB.  If  this  value  is  not  present,  then  the 
value  retained  in  step  2)a)  is  used  in  the  signature  verification  process  m  step  4)e). 

c)  verifies  that  die  identifier  for  the  initiator  has  been  obtained  in  one  of  three  ways:  m 
CertA,  TokenAB,  or  the  authentication  request  in  step  1),  depending  on  which 
optional  information  has  been  mcluded.  In  the  event  that  certificates  are  not  used  for 
signature  verification,  then  the  identifier  for  endty  A  should  be  used  to  retrieve  the 
initiator's  public  key  in  some  unspecified  manner,  continue  with  step  4)e). 

d)  verifies  the  initiator's  certificate  or  certificate  chain,  assuming  certificates  are  used  (see 
Section  3.1.4). 

e)  verifies  the  initiator's  signature  in  TokenAB. 

f)  [OPTIONAL]  retrieves  data  from  the  B,  Tcxt2,  and  Text3  fields,  using  them  in  a 
manner  which  is  outside  the  scope  of  this  standard. 

Successful  completion  of  parts  b)  through  e)  in  step  4)  means  that  the  initiator.  A,  has 
authenticated  itself  to  the  responder,  B.  If  any  of  the  verifications  in  parts  b)  through 
e)  fail,  then  the  authentication  exchange  is  terminated.  If  certain  conditions  either  are  or 
are  not  met  in  die  optional  parts  a)  and  f),  the  responder  may  choose  to  terminate  the 
authentication  exchange;  these  conditions  are  implementation-specific,  and  outside  the  scope 
of  this  standard. 
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5)  The  responder,  B, 


# 


a)  [OPTIONAL]  selects  an  identifier  for  the  initiator,  and  includes  that  in  the  A  field  of 
TokenBAj  below. 

b)  [OPTIONAL]  generates  and/or  selects  other  data  which  is  to  be  included  in  the  Text4 
and  Text5  fields.  In  TokenBAj,  Text4  is  a  subset  of  die  Text5  field  -  this  includes 
cases  where  Text4  is  the  NULL  set,  and  where  Text4  equals  Textf. 

The  responder  creates  an  authentication  token,  TokenBAj,  by  concatenating  data  and 
generating  a  digital  signature: 

TokenBA,  -  [RJ  ||  [RJ  ||  [A]  ||  [TextS]  ||  sS,(  R,  ||  RA  ||  [A]  ||  [Tex»4]  ) 

The  signed  data  that  are  marked  as  optional  are  present  only  when  their  corresponding 
values  are  present  in  the  unsigned  part  of  TokenBAj  Although  RA  and  RB  do  not  have  to 
be  in  die  unsigned  data  of  TokenBAj,  they  must  be  included  in  die  signed  data  (see  Section 
22). 

In  addition  to  containing  TokenBAj  the  message  may  optionally  include  a  token  identifier, 

TokenID,  and  die  responder’s  certificate  (or  chain  of  certificates),  CertB.  The  message  from 

the  responder  to  the  initiator  is  of  the  form:  4 

[TokenID]  ||  [  CertB  ]  ||  TokenBAj 

6)  Upon  receiving  die  message  including  TokenBAj,  the  initiator.  A, 

a)  [OPTIONAL]  uses  TokenID  to  determine  which  token  is  being  received. 

b)  verifies  that  the  value  of  RA  is  the  same  as  the  value  retained  in  step  3)c),  given  that 

Ra  is  present  in  TokenBAj.  If  this  value  is  not  present,  then  the  value  retained  in  step 

3)c)  is  used  in  the  signature  verification  process  in  step  6)f). 

c)  verifies  that  die  value  of  Rb  is  the  same  value  as  the  RB  field  retrieved  from 

TokenBA,,  given  that  RB  is  present  in  TokenBAj  If  this  value  is  not  present,  then 
the  value  of  Rb  retrieved  from  TokenBA,  is  used  in  the  signature  verification  process 
in  step  6)f). 

d)  verifies  that  die  identifier  for  the  responder  has  been  obtained  in  one  of  three  ways: 
in  CertB,  TokenBAj,  or  TokenBA,,  depending  on  which  optional  information  has  been 
included.  In  the  event  that  certificates  are  not  used  for  signature  verification,  then  the 
identifier  for  entity  B  should  be  used  to  retrieve  the  initiator’s  public  key  in  some 
unspecified  manner;  continue  with  step  6)0- 
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e)  verifies  the  responder1  s  cei uficate  or  Cci  uficate  chain.  accnminp  cemricsies  sre  used 
(see  Section  3.1.4). 

f)  verifies  the  responder's  signature  on  TokenBA,. 

g)  [OPTIONAL]  retrieves  data  from  the  A,  Text4,  and  Text5  fields,  using  them  in  a 
manner  which  is  outside  the  scope  of  this  standard. 

Successful  completion  of  parts  b)  through  f)  in  step  6)  means  that  the  responder.  B. 
has  authenticated  itself  to  the  initiator.  A,  and  thus  the  entities  have  successfully 
mutually  authenticated.  If  any  of  the  verifications  in  pans  b)  through  f)  fail,  then  the 
authentication  exchange  is  terminated.  If  cenain  conditions  either  are  or  are  not  met  in  the 
optional  parts  a)  and  g),  the  initiator  may  choose  to  terminate  the  authentication  exchange  - 
these  conditions  are  implementation-specific,  and  outside  the  scope  of  this  standard. 


Appendix  A 


Example  Authentication  Tokens 
Using  ASN.l  Notation  and  CER/DER  Encoding 

This  appendix  is  provided  for  informational  purposes  only,  and  is  not  pan  of  this  standard  The 
purpose  of  this  appendix  is  to  provide  implementors  of  this  standard  with  an  opnonal  set  of  rules 
for  formatting  and  encoding  authentication  tokens  and  messages  from  Section  3  of  this  standard 
Abstract  Syntax  Notation  One  (ASN.l)  is  used  to  format  authentication  tokens  and  messages, 
which  are  then  encoded  using  Canonical  Encoding  Rules  (CER)  or  Distinguished  Encoding  Rules 
(DER).  This  appendix  also  specifies  optional  representations  of  other  data  such  as  public  key 
certificates.  The  implementation  of  a  unique  set  of  encoding  rules  is  necessary  for 
interoperability  to  take  place  between  various  authentication  domains. 

The  reader  should  note  that  in  ASN.l  notation,  optional  fields  are  indicated  with  the  word 
"OPTIONAL",  and  not  with  square  brackets  "[  ]",  as  used  in  die  body  of  this  standard.  In  ASN.l 
notation,  square  brackets  are  used  to  indicate  tagged  fields. 


A.1  Abstract  Syntax  Notation  One  (ASN.l) 

This  example  definition  is  specified  using  the  Abstract  Syntax  Notation  One  (ASN.l).  ASN.l 
is  an  international  standard  used  by  ISO  and  ITU  (previously  CCITT)  protocols  as  well  as  many 
Internet  protocols.  It  is  comprised  of  two  parts:  the  ASN.l  notation  [1-4]  and  the  ASN.l 
encoding  rules  [5]. 

The  ASN.l  notation  is  an  abstract  specification  language  used  to  describe  the  local  representation 
of  data.  It  allows  the  description  of  the  complex  data  types  carried  in  protocol  messages,  without 
concern  for  the  underlying  binary  representation. 

The  ASN.l  encoding  rules  go  hand-m-hand  with  the  ASN.l  notation.  Whereas  the  ASN.l 
notation  provides  an  abstract  specification  of  the  local  representation  of  data,  the  ASN.l  encoding 
rules  define  the  external  representation  of  the  data.  In  order  to  correctly  interpret  the 
binary-pattern  representation  of  a  data  value,  it  is  necessary  to  know  (usually  from  the  context), 
the  type  of  the  value  being  represented,  as  well  as  the  encoding  mechanism  used  to  convert  the 
value  from  its  local  representation  to  its  external  representation.  The  ASN.l  encoding  rules 
define  "tags"  that  are  added  to  a  data  value  to  indicate  the  data  type  and  length  representation. 
The  encoding  rules  also  defme  the  actual  bit  representation  of  the  data  value. 

There  may  be  more  than  one  set  of  encoding  rules  that  can  be  applied  to  data  values  that  are 
defined  using  the  ASN.l  notation.  The  ASN.l  encoding  rules  standard  defines  three  sets  of 
encoding  rules,  namely:  basic  encoding  rules,  canonical  encoding  rules,  and  distinguished 
encoding  rules.  Whereas  the  basic  encoding  rules  give  the  sender  of  an  encoding  various  choices 
as  to  how  data  values  may  be  encoded,  the  canonical  and  distinguished  encoding  rules  select  just 


one  encoding  from  those  allowed  by  the  basic  encoding  rules,  allowing  the  receiver  to 
unambiguously  decode  the  ASN.l  notation.  The  use  of  canonical  or  distinguished  encodings  is 
essential  with  protocol  messages  containing  digitally  signed  data  values,  so  that  the  receiver  can 
verify  the  digital  signature  over  the  .same  exact  data  representation  used  by  the  sender  to  generate 
die  signature. 

The  canonical  and  distinguished  encoding  rules  differ  from  each  other  in  the  set  of  restrictions 
they  place  on  the  basic  encoding  rules.  The  distinguished  encoding  rules  are  more  suitable  if  the 
iruyviffH  value  is  small  enough  to  fit  into  the  available  memory  and  there  is  a  need  to  rapidly  skip 
over  some  nested  values.  The  canonical  encoding  rules  are  more  suitable  if  there  is  a  need  to 
encode  values  that  are  so  large  that  they  cannot  readily  fit  into  the  available  memory  or  it  is 
necessary  to  encode  and  transmit  part  of  a  value  before  the  entire  value  is  available. 


A 2  ASN.l  Specification  of  Entity  Authentication  Tokens  and  Messages 

F-arh  protocol  message  is  potentially  comprised  of  three  components,  an  optional  token  identifier, 
optional  public-key  certification  data,  and  an  authentication  token. 

MessageBA,  is  used  in  the  unilateral  authentication  exchange  and  is  sent  by  the  verifier  to  the 
claimant  MessageBA,  is  also  used  in  the  mutual  authentication  exchange  and  is  sent  by  the 
responder  to  the  initiator.  MessageBA,  contains  an  optional  token  identifier  and  authentication 
token  BA,. 

-  tokenlcLtokenType  ■  0x0001  tor  unilateral  authentication 

-  tokenlcLtokenType  ■  0x001 1  tor  mutual  authentication 

Messa9eBA:  SEQUENCE  { 

tokenld  [0]  Tokenld  OPTIONAL, 

tokenBAj  TokeaBAi 


TokenBAj  :  :  =  SEQUENCE  { 

ranB  RandomNumber , 

textl  Text  OPTIONAL 


MessagcAB  is  used  in  the  unilateral  authentication  exchange  and  is  sent  by  the  claimant  to  the 
verifier.  MessageAB  is  also  used  in  the  mutual  authentication  exchange  and  is  sent  by  the 
initiator  to  the  responder.  MessageAB  contains  an  optional  token  identifier,  optional  certification 
information,  and  authentication  token  AB. 

-  tokenlcLtokenType  ■  0x0002  tor  unilateral  authentication 

-  tokenld.tokenType  •  0x0012  tor  mutual  authentication 
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MessageAB  : : =  SEQUENCE  { 

tokenld  [0]  Tokenld  OPTIONAL, 
certA  [1]  CertData  OPTIONAL, 
tokenAB  TokenAB 


TokenAB  : : *  SEQUENCE  { 
ranA 
ranB 
entityB 
text3 
signature 


-  if  entityB  is  included  in  TokenAB,  then  it  shall  also  be  included  in  SigDataAB 


RandomNunber, 
RandamNuaber  OPTIONAL, 
EntityName  OPTIONAL, 
Text  OPTIONAL, 

SIGNATURE  {  SigDataAB  } 


SigDataAB  :  :*=  SEQUENCE  { 
ranA 
ranB 
entityB 
text2 

} 


RandomNunber , 

RandomNunber , 

EntityName  OPTIONAL, 

Text  OPTIONAL  -  subset  of  text3 


MessageBA2  is  used  in  the  mutual  authentication  exchange  and  is  sent  by  the  responder  to  the 
initiator.  MessageBA2  contains  an  optional  token  identifier,  optional  certification  information, 
and  authentication  token  BA^ 


-  tokenld.tokenType  *  0x0013 


MessageBAj  =  SEQUENCE  { 
tokenld 
certB 
tokenBAj 


[0]  Tokenld  OPTIONAL, 
[1]  CertData  OPTIONAL, 
TokenBA2 


TokenBAj  :  :  =  SEQUENCE  { 

ranB  [0] 

ranA  [ 1 j 

entityA 

text5 

signature 


RandomN umber  OPTIONAL, 
RandomN umber  OPTIONAL, 
EntityName  OPTIONAL, 
Text  OPTIONAL, 

SIGNATURE  {  SigDataBAj  } 


-  if  entityA  is  included  in  TokenBAj  then  it  shall  also  be  included  in  SigDataBAj 


SigDataBAj  SEQUENCE  { 

ranB  RandomN umber , 

ranA  RandomNumber , 

entityA  EntityName  OPTIONAL, 

text4  Text  OPTIONAL  -  subset  of  teXtS 


The  token  identifier  is  defined  here  to  include  the  type  of  token  and  the  protocol  version  number. 
This  version  is  defined  here  as  Version  2,  to  distinguish  it  from  Version  1,  which  was  defmed 
in  an  earlier  draft  of  this  appendix. 


INTEGER, 

INTEGER  {v2 (2) } , 


Tokenld  : : *  SEQUENCE  { 
tokenType 
protoVerNo 

} 


The  certification  data  includes  a  certification  path  and/or  a  certificate  revocation  list.  The 
definitions  for  CertificationPath  and  CertifieateList  are  imported  from  ITU-T  Rec.  X.509  | 
ISO/IEC  9594-8,  The  Directory:  Authentication  Framework  [6],  and  are  given  below  m  Section 
A3. 


CertData  : :*  SEQUENCE  { 

certPath  [0]  CertificationPath  OPTIONAL, 

certRevList  [1]  CertifieateList  OPTIONAL 

}  -  at  least  orm  ot  the  components  above  shall  be  present 


A  random  number  is  simply  defined  as  an  octet  string. 

RandamNumber  OCTET  STRING 


An  entity  name  is  defined  as  the  alternative  name  forms  defined  in  Draft  Amendment  I  to  ITU-T 
Rec.  X.509  |  ISO/IEC  9594-8  on  Certificate  Extensions  [7]. 


EntityName  AltNames 


AltNames  SEQUENCE 

OF  CHOICE 

{ 

otherName 

10] 

INSTANCE  OF  OTHER -NAME, 

rf c822Name 

ID 

I A5 String, 

dNSName 

[2] 

IA5 String, 

x4 00 Address 

[3] 

ORAddress, 

directoryName 

[4] 

Name, 

edi Par t yName 

[5] 

IA5 String 

} 


OTHER -NAME  TYPE- IDENTIFIER 

Text  contains  undetermined  data  which  may  be  included  at  the  discretion  of  a  specific 
implementation  of  this  standard.  Therefore,  it  is  defined  here  to  simply  be  a  bit  string.  The  text 
data  used  in  a  specific  implementation  shall  be  defined  and  encoded  using  ASN.l  or  some  other 
data  representation.  In  either  case,  the  resulting  data  shall  be  unambiguously  encoded  (e.g.,  using 
ASN.l  distinguished  or  canonical  encoding  rules)  and  shall  be  represented  here  as  a  bit  string. 

Text  : :  =  bit  string  -  contains  encoded  text  data 


29 


AJ  ASN.l  Specification  of  Public-Key  Certification  Information 


The  definitions  for  CertificatePath  and  CertificateList  arc  taken  from  Annex  A  of  ITU-T  Rec 
X.509  |  ISO/IEC  9594-8,  The  Directory.  Authentication  Framework  [6].  These  definitions 
describe  Version  2  certificates  and  certificate  revocation  lists.  Version  3  certificate  extensions 
can  be  found  in  Draft  Amendment  1  to  ITU-T  Rec.  X.509  |  ISO/IEC  9594-8  on  Certificate 
Extensions  [7]. 


-types- 


CertificationPath  ::=  SEQUENCE  { 

userCertif icate  Certificate, 

theCACertif icates  SEQUENCE  OF  Certif icatePair  OPTIONAL 

} 


SIGNED  {  SEQUENCE  { 


CertificateList  : : 
signature 
issuer 
lastUpdate 
revokedCertif icates 
signature 
issuer 

userCertif icate 
revocationDate 
}}  OPTIONAL 

}} 


Algorithmldentif ler , 

Name, 

UTCTime, 

SIGNED  {  SEQUENCE  OF  SEQUENCE  { 
Algorithmldentif ier , 

Name, 

Certif icateSerialNumber , 
UTCTime 


Certif icatePair  ::  =  SEQUENCE  { 

forward  [0]  Certificate  OPTIONAL, 

reverse  [lj  Certificate  OPTIONAL 

}  -  at  least  one  of  the  pair  shall  be  present 


Certificate  ::=  SIGNED  {  SEQUENCE  { 


[0] 


version 
serialNumber 
signature 
issuer 
validity 
subject 

subjectPublicKeylnf o 
issuerUnigueldentif ier 


subjectUnigueldentif ier 


Version  DEFAULT  vl 
Certif icateSerialNumber , 

Algorithmldentif ier , 

Name, 

Validity, 

Name, 

Sub j  ectPublicKeylnf o , 

[1]  IMPLICIT  Unigueldentif ier  OPTIONAL, 

-  if  present,  version  must  be  v2 

[2]  IMPLICIT  Unigueldentif ier  OPTIONAL 

-  it  present,  version  must  be  v2 


}} 


Version  : INTEGER  {vl (0) ,  v2(l)} 


Certif icateSerialNumber  ::=  INTEGER 


Algorithmldentif ier  =  SEQUENCE  { 

algorithm  ALGORITHM. i id ( {SupportedAlgorithms} )  , 

parameters  ALGORITHM . &Type ( {SupportedAlgorithms} {©algorithm} ) 

OPTIONAL 


} 


-  Definition  of  the  following  information  object  set  its  deferred,  perhaps  to  standardized 


-profiles  or  to  protocol  implementatni  conlonnance  statements.  The  set  b  mound  to 

-  specify  a  table  constraint  on  the  parameters  component  of  Algorfthmldenttfier 

-  Support edAlgorithms  ALGORITHM  :  :=  { _  |  _ } 

Validity  SEQUENCE  { 

notBefore  UTCTime, 

notAf ter  UTCTime 

} 

SubjectPublicKeylnf o  SEQUENCE  { 

algorithm  AlgorithraTdentif ier, 

subjectPublicKey  BIT  STRING 

} 

-  information  object  Passes  - 

ALGORITHM  TYPE - IDENTIFIER 

-  parameterized  types  - 

SIGNED  {  ToBeSigned  }  SEQUENCE  { 

ToBeSigned, 

COMPONENTS  OF  SIGNATURE {ToBeSigned} 

} 

SIGNATURE  {  Of Signature  }  SEQUENCE  { 

Algori thmldentif ier , 

ENCRYPTED  {  HASHED  {  Of Signature  }} 

} 

ENCRYPTED  {  ToBeEnciphered  }  : : *  BIT  STRING  (  CONSTRAINED  BY  { 

-  must  be  the  result  of  applying  an  enophemient  procedure  - 

-to  the  BER-encoded  octets  of  a  value  of  -  ToBeEnciphered 

}) 

HASHED  {  ToBeHashed  }  : : =  OCTET  STRING  (  CONSTRAINED  BY  { 

-  must  be  the  result  of  applying  a  hashing  procedure  to  the - 

-  DER-encoded  octets  of  a  value  of  -  ToBeHashed 

}) 


The  definition  for  Uniqueldentifier  is  imported  from  Annex  A  of  ITU-T  X.520  |  ISO/IEC  9594- 
6,  The  Directory:  Selected  Attribute  Types  [8]. 

Uniqueldentifier  BIT  STRING 

The  definition  for  Name  is  taken  from  Annex  B  of  ITU-T  Rec.  X.501  |  ISO/IEC  9594-2,  The 
Directory:  The  Models  [9]. 

-  naming  data  types  - 

Name  ::=  CHOICE  {RDNSeguence  -  one  possibility  tor  now  -} 

RDNSequence  ::=  SEQUENCE  OF  RelativeDistinguishedName 
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RelativeDistinguishedName  SET  SIZE (1  ..  MAX)  OF  AttributeTypeAndValue 

-attribute data  types - 

AttributeTypeAndValue  : : =  SEQUENCE { 

type  AttributeType ( {SupportedAttributes} ) . 

value  AttributeValue USupportedAt tributes } ifftvpe} ' 

} 

AttributeType  ATTRIBUTE . Sid 

AttributeValue  : : *  ATTRIBUTE . SType 

-  Definition  of  the  totkmng  information  object  set  its  deferred,  perhaps  to  standardized 

-  profiles  or  to  protocol  implementation  conformance  statements.  The  set  is  required  to 

-  specify  a  table  constraint  on  the  value  component  of  AttributeTypeAndValue 

-  SupportedAttributes  ATTRIBUTE  : : *  {  —  |  ...  } 

The  reader  should  consult  Annex  B  of  ITU-T  Rec.  X.501  |  ISO/IEC  9594-2  [9]  for  the 
ATTRIBUTE  information  object  class  specification. 


* 


Appendix  B 


Example  Authentication  Token  Formatting  and  Encoding  Based  on  the 
Simple  Public-Key  GSS-API  Mechanism  (SPKM)  Specification 

This  appendix  is  provided  for  informational  purposes  only,  and  is  not  pan  of  this  standard  The 
purpose  of  this  appendix  is  to  provide  implementors  of  this  standard  with  an  opnonaJ  method  for 
formatting  and  encoding  authentication  tokens  in  Section  3  of  this  standard. 

The  Simple  Public-Key  GSS-API  Mechanism  (SPKM)  Specification  is  an  Internet  Proposed 
Standard  (RFC  2025)  [10]  that  describes  several  challenge-response  mechanisms  to  enable  entity 
authentication  using  public-key  cryptography.  That  specification  "defines  protocols,  procedures, 
and  conventions  to  be  employed  by  peers  implementing  the  Generic  Security  Service  Application 
Program  Interface  (as  specified  in  RFCs  1508  [11]  and  1509  [12])  when  using  the  Simple 
Public-Key  Mechanism."  [10]  The  SPKM-1  GSS-API  mechanism  is  capable  of  implementing 
both  authentication  exchanges  described  in  this  standard,  while  taking  advantage  of  optional  token 
fields  and  authentication  steps  in  Section  3.  SPKM-1  also  provides  implementors  with  a  means 
to  establish  a  key  between  the  authenticating  entities  and  protect  the  confidentiality  of  data.  The 
SPKM-2  mechanism  in  [10]  is  not  addressed  in  this  appendix  because  it  relies  on  timestamps  - 
not  signed  random  number  challenges  -  to  authenticate  entities  to  one  another. 

By  using  GSS-API,  entities  implementing  SPKM  authentication  can  perform  context 
establishment,  algorithm  negotiation  and  key  establishment  For  purposes  of  this  appendix.  non- 
FIPS  approved  security  methods  referenced  in  [10]  will  not  be  discussed  in  the  following 
sections. 


B.l  ASN.l  Specification  of  SPKM  Tokens  and  Messages 

SPKM  describes  the  various  GSS-API  tokens  that  are  to  be  passed  between  entities  to  perform 
unilateral  and  mutual  authentication.  This  section  describes  the  formats  of  those  tokens  in  ASN.l 
notation,  which  is  explained  in  Appendix  A.  Section  A.l.  What  follows  is  not  a  complete  list 
of  ASN.l  formatted  tokens  for  the  SPKM-1  mechanism,  and  this  list  does  not  completely 
describe  those  tokens  or  the  steps  necessary  for  performing  SPKM-1  authentication  using  GSS- 
API.  For  example,  other  optional  SPKM  GSS-API  tokens  (not  equivalent  to  authentication 
tokens  described  in  this  FIPS)  may  be  implemented  to  provide  for  the  data  integrity  and 
encryption  of  the  SPKM-1  authentication  tokens  (SPKM-REQ,  SPKM- REP  -  TI,  and  SPKM- 
REP  -  IT).  Such  GSS-API  tokens  may  also  be  used  for  error  recovery  during  an  authentication 
exchange.  The  implementor  should  consult  the  SPKM  specification  in  [10]  to  obtain  complete 
details  on  implementing  an  SPKM-1  mechanism. 

In  the  token  and  message  descriptions  below,  SPKM  terminology  differs  slightly  from 
terminology  defined  in  Section  2.3  of  this  FIPS.  The  SPKM  specification  refers  to  an  "initiator" 
and  "target".  When  performing  either  unilateral  or  mutual  SPKM-1  authentication,  the  "initiator" 


► 
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is  the  equivalent  of  entity  B  in  this  FIPS,  and  the  "target"  is  the  equivalent  of  entity  a.  The 
"initiator"  in  SPKM  authentication  is  actually  the  "responder"  described  in  the  mutual 
authentication  exchange  in  Section  33. 


SpkmGssTokens  {iao(l)  identified -organization (3)  dod(6)  internet (1) 

aeeurity(5)  mechanisms  (5)  spkmd)  spkmGssTokens  (10)  } 

--  types 

Certif icationData  SEQUENCE  { 

certif icationPath  10]  Certif icationPath  OPTIONAL. 

certificateRevocationList  11]  Certif icateList  OPTIONAL 

}  -  -  at  least  one  of  the  above  shall  be  present 


Certif icationPath 

SEQUENCE 

{ 

userKeyZd 

[0] 

OCTET  STRING  OPTIONAL, 

userCertif 

Ill 

Certificate  OPTIONAL, 

verif Keyld 

[2] 

OCTET  STRING  OPTIONAL, 

userVer if Certif 

[3] 

Certificate  OPTIONAL, 

theCACertificates 

[4] 

SEQUENCE  OF  Certif icatePair  OPTIONAL 

}  -•  Presence  of  [2]  or  [3]  implies  that  [0]  or  [1]  must  also  be 


••  present.  Presence  of  [4]  implies  that  at  least  one  of  [0],  [1] , 
--  [2] ,  and  [3]  must  also  be  present. 


--  The  requestToken  in  SPKM-REQ  represents  TokenBAj  in  the  FIPS  -- 
--  authentication  exchanges .  It  contains  B's  random  challenge  to  A. 


SPKM-REQ  SEQUENCE  { 
requestToken 
certif -data  [0] 

auth-data  [1] 


REQ- TOKEN. 

Certif icationData  OPTIONAL 
AuthonzationData  OPTIONAL 


REQ -TOKEN  SEQUENCE  { 

req- contents 
algid 

req- integrity 


Req -  contents , 

Algonthmldentif  ier , 

Integrity  --  "token"  is  Req-contents 


Integrity  =  BIT  STRING 

--  See  the  special  note  in  [10]  regarding  this  type. 


Req-contents  SEQUENCE 

tok-id 
context - id 
pvno 

timestamp 
randS re 
targ-name 
src-name  [0] 

req -data 

validity  (11 

key-estb-set 
key-estb-req 
key- src -bind 

1 


INTEGER  (256),  --  shall  contain  0100  (hex) 

Random • Integer , 

BIT  STRING, 

UTCTime  OPTIONAL, 

Random- Integer , 

Name, 

Name  OPTIONAL, 

Context -Data, 

Validity  OPTIONAL, 

Key-Estb-Algs, 

BIT  STRING  OPTIONAL, 

OCTET  STRING  OPTIONAL 


Random- Integer  ::=  BIT  STRING 
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Context -Data  SEQUENCE  { 

channelld 
seq- number 
options 
conf -alg 
intg-alg 
owf -alg 


Channelld  OCTET  STRING 

Options  BIT  STRING  { 
delegation* 8 tate  (0), 
mutual -state  (1) , 
replay-det- state  (2) , 
sequence -state  (3)  , 
conf -avail  (4), 
integ -avail  (5) , 
target- certif -data -required 


Conf-Algs  CHOICE  { 

algs  [0]  SEQUENCE  OF  Algorithmldentif ier , 

null  [1]  NULL 

}  --  confidentiality  algorithms 

Intg-Algs  ::=  SEQUENCE  OF  Algorithmldentif ier  --  integrity  algorithms 
OWF-Algs  SEQUENCE  OF  Algorithm! dent if ier 

Key-Estb-Algs  SEQUENCE  OF  Algorithmldentif ier  -*  key  establishment 

--  algorithms 


Channelld  OPTIONAL, 
INTEGER  OPTIONAL, 
Options, 

Conf-Algs, 

Intg-Algs, 

OWF-Algs 


Algorithmldentif ier  SEQUENCE  { 

algorithm  OBJECT  IDENTIFIER, 

parameter  ANY  DEFINED  BY  algorithm  OPTIONAL 

}  --  Note  that  the  1993  AuthenticationFramework  module  in  [6]  uses 

-*  different  syntax  for  this  construct. 


The  responseToken  in  SPKM-REP-TI  represents  TokenAB  in  the  FIPS  -- 
authentication  exchanges.  It  contains  A's  signature  on  B's  challenge, 
and  a  random  challenge  to  B  during  mutual  authentication.  -- 

SPKM-REP-TI  SEQUENCE  { 

responseToken  REP -TI -TOKEN, 

certif -data  Certif icationData  OPTIONAL 

--  present  if  target -certif -data -required  option  was 
--  set  to  TRUE  in  SPKM-REQ 

} 

REP -TI- TOKEN  : SEQUENCE  { 

rep- ti- contents  Rep- ti- contents, 

algid  Algorithmldentif ier, 

rep -ti- integ  Integrity  --  “token"  is  Rep- ti -contents 

} 


( 


Rep  ■  ti  *  contents  : 
tok-id 
context  - id 
pvno 

timestamp 
randTarg 
arc -name 
tar g -name 
randSrc 
rep -data 
validity 
key-estb*id 
key-estb-str 

} 


SEQUENCE  { 

INTEGER  (512),  -•  shall  contain  020C  (hex1 

Random - Integer , 

[0)  BIT  STRING  OPTIONAL, 

UTCTime  OPTIONAL, 

Random *  Integer , 

[1]  Name  OPTIONAL, 

Name, 

Random  *  Integer , 

Context -Data, 

[2]  Validity  OPTIONAL, 

Algor ithml den tifier  OPTIONAL, 

BIT  STRING  OPTIONAL 


*  The  responaeToken  in  SPFM-REP-IT  represents  TokenBA:  in  the  FIPS  -- 

*  mutual  authentication  exchange.  It  contains  B's  signature  on  -- 

*  A1  s  random  challenge.  -• 


SPKM-REP-IT  SEQUENCE  { 
responaeToken 
algid 

rep* it* in teg 

) 

REP  *  IT • TOKEN  SEQUENCE  { 
tok ■ id 
context - id 
randSrc 
randTarg 
targ-name 
srcname 
key-estb-rep 

} 


REP -IT -TOKEN, 

Algori  thmldentif  ier , 

Integrity  -•  "token"  is  REP -IT -TOKEN 


INTEGER  (768),  --  shall  contain  0300  (hex) 

Random- Integer , 

Random • Integer , 

Random - In teger , 

Name, 

Name  OPTIONAL, 

BIT  STRING  OPTIONAL 


other  types  -  - 
--  from  [11] 


MechType  OBJECT  IDENTIFIER 


InitialContextToken  ::= 
thisMech 

innerContextToken 


) 


[APPLICATION  0]  IMPLICIT  SEQUENCE  { 

MechType, 

SPKMInnerContextToken 

--  when  thisMech  is  SPKM-1  or  SPKM-2 


SPKMInnerContextToken  ::=  CHOICE  { 


req 

[0] 

SPKM-REQ. 

rep- ti 

(1) 

SPKM-REP-TI, 

rep- it 

[2] 

SPKM-REP-IT, 

error 

13) 

SPKM- ERROR, 

mic 

[4] 

SPKM-MIC, 

wap 

[5] 

SPKM-WRAP, 

del 

[6] 

SPKM -DEL 
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--  object  identifier  assignments  * 


sptan-1  OBJECT  IDENTIFIER  : := 

{iso(l)  identified -organization (3)  dod(6)  internet (1)  security (5 
mechanisms  (5)  ap)an(l)  spkm-ld)} 


--  The  following  two  object  identifiers  for  signature  algorithms  are  derived 
--  from  "Stable  Implementation  Agreements  for  Open  Systems  Interconnection 
--  Protocols:  Part  12  -  OS  Security"  [13].  This  document  was  prepared  sv 
--  the  Security  Special  Interest  Group  (SECSIG)  of  the  Open  Systems 
--  Environment  Implementors '  Workshop  (OIW)  hosted  by  NIST.  The  OIK  has 
--  registered  the  following  algorithms  with  ISO.  The  DSA  and  SHA-l  are 
--  examples  of  a  current  FIPS  approved  digital  signature  and  secure  hash 
--  algorithm,  respectively.  Although  these  examples  are  not  giver,  m  [10], 
--  the  SPKM  specification  states  that  the  examples  included  in  [10],  "  land 
--  any  other  algorithms)  may  optionally  be  supported  by  a  giver.  SPKM 
--  implementation"  [10]. 

dsaWithSHAl  OBJECT  IDENTIFIER  ::*=  { 

iso(l)  identified -organization (3)  oiw(14)  secsig(3) 
algorithm (2)  27 

} 


dsaCommonWi thSHAl  OBJECT  IDENTIFIER  ::=  { 

iso(l)  identified -organization (3)  oiw(14)  secsig(3) 
algorithm (2)  26  --  uses  common  parameters  p,  q, 

-  -  are  distributed  externally 


} 


and  g,  which 


B.2  ASN.l  Specification  of  Public-Key  Certification  Information 

The  SPKM-1  mechanism  uses  many  certificate-related  ASN.l  types  that  are  derived  from  [6]  and 
[9],  which  are  either  the  same  as  or  similar  to  the  definitions  listed  in  Section  A.3  of  Appendix 
A  in  this  FIPS.  Rather  than  repeat  them  here  and  note  the  differences,  the  implementor  should 
consult  Appendix  B  of  the  SPKM  specification  [  1 0]  for  more  complete  details. 


t 
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Appendix  C 

Example  Authentication  Token  Formatting  Based  on  ANSI  X9.26-1990 


This  appendix  is  provided  for  informational  purposes  only,  and  is  not  part  of  this  standard.  The 
purpose  of  this  appendix  is  to  provide  implementors  of  this  standard  with  an  opnonal  method  fo: 
formatting  authentication  tokens  horn  Section  3  of  this  FIPS.  Formatting  specifications  are  based 
on  message  formats  defined  in  ANSI  X9.26-1990,  Financial  Institution  Sign-On  Authentication 
for  Wholesale  Financial  Transactions  [14].  Note  that  these  formatted  tokens  may  additionally 
have  to  be  encoded  before  transmission,  depending  on  die  nature  of  a  particular  implementation. 
One  possible  encoding  process  is  described  in  Appendix  D  of  this  standard. 

C.1  Background' 

When  authentication  is  conducted  within  a  security  services  protocol,  the  protocol  definition 
generally  specifies  where  die  authentication  information  is  located  and  how  it  is  represented.  The 
individual  token  fields  may  be  represented  as  elements  in  a  data  structure,  or  they  may  be 
encoded  into  a  transmission  unit  using,  for  example,  the  ASN.l/DER  formatting  and  encoding 
described  in  Appendix  A.  However,  many  implementations  of  the  FIPS  authentication  protocols 
may  not  be  capable  of  handling  (or  require  the  overhead  of)  ASN.l/DER  formatting  and 
encoding.  Therefore,  this  appendix  provides  an  ASCII-based  alternative.  In  this  appendix,  the 
token  fields  are  formatted  based  on  notation  and  message  formats  in  ANSI  X9.26  [14].  That 
standard  addresses  several  types  of  sign-cm  authentication  that  use  secret-key,  not  public-key 
cryptography.  However,  with  slight  modifications  to  field  tags,  function  definitions,  and  message 
formats,  an  ANSI  X9.26-"like"  implementation  can  perform  either  of  the  FIPS  authentication 
protocols. 

C.2  Token  and  Message  Formats  Based  on  ANSI  X9.26 

As  indicated  above,  this  appendix  will  allow  an  implementor  to  generate  authentication  tokens 
based  on  message  formats  described  in  ANSI  X9.26.  The  abbreviations,  notation,  and  basic 
functions  described  below  were  drawn  from  [14],  with  additions  or  slight  modifications,  which 
are  marked  with  an  asterisk  ("*"). 

C.2.1  Abbreviations 

The  message  formats  described  in  Table  I  below  assume  the  use  of  certain  abbreviations,  some 
of  which  are  based  on  abbreviations  in  [14]. 


Table  I:  Formatting  abbreviations  based  on  ANSI  X9.26 


APBREV.  MEANING  ' 

£  ■'•CRA  -  „  EatxQr-A'aJublk  Key  .Certificate 

■  «CRB  Er&ylftt  Public  Key  Certificate 

DATA 

"f 

•GSA 

GSF  geoented  by  entity  A 

*GSB 

GSF  generated  by  entity  B 

GSF 

General  Security  Function 

INPUT 

Input 

•KPRI 

Private  Key. 

MCL 

Message  Class 

ORG 

Originator  —  . 

RCV 

Recipient 

•SMA 

Entity  A's  SOM 

•SMB 

Entity  B's  SOM 

SOM 

Sign-on  Message 

TTM 

TVP  Transmission  Message 

•TVA 

Initiator's  TVP 

•TVB 

Responder's  TVP 

TVP 

Time  Variant  Parameter 

REMARKS 

A  public  key  certificate  bmdmg  ennry  A  to  us 
poblic/pnvaxe  key  pair. 

A  public  key  ccrd.fi  cate  binding  canty  B  to  its 
pubfic/private  key  pair. 

..  A  menage  involved  in  dealing  a  service  (such  as 
._authcnticaaap)  using  cryptography. 

The  input  of  the  Crypto  Function  (&£..  the  result 
of  the  Combine  Funcnon). 

Output  of  Ihe  GSF  ynrratrai  with  entity  A's  KPRI. 

Output  of  the  GSF  with  entity  B's  KPRI. 

*  Function  used  to  authenticate  ORG  to  RCV. 

The  input  of  the  Select  Function  (e.g.,  the  result  of 
the  Crypto  Function). 

Key  used  to  generate  a  digital  signature. 

The  tag  for  the  field  that  defines  the  type  of  CSM. 

The  entity  sending  the  CSM. 

The  entity  receiving  the  CSM. 

Sign-an  Message  with  entity  A's  digital  signature. 

Sign-on  Message  with  entity  B's  digital  signature. 

An  MCL  used  in  the  sign-on  authentication  CSM. 

An  MCL  used  in  the  sign-on  authentication  CSM. 

A  TVP  generated  by  die  initiator,  A 

A  TVP  generated  by  the  responder,  B. 

A  random  or  pseudorandom  number  generated  with 
a  FIPS  approved  random  number  generator. 


C22  Notation 


The  following  notation  shall  be  used  when  formatting  authenncauon  tokens  as  described  in 

Section  C23  of  this  appendix: 

1)  The  character  set  for  Cryptographic  Service  Messages  shall  be  the  following  characters 
digits  (0-9),  letters  (A-Z),  comma  (,),  period  (.),  space  (b),  solidus  (/).  hyphen  (-).  asterisk 
(*),  and  open  and  close  parentheses  ((&)).  The  character  Qj)  shall  only  be  used  in  a 
message  to  separate  fields.  The  character  (.)  shall  only  be  used  in  a  field  to  separate 
subfields  (if  inquired). 

2)  The  presence  of  a  Cryptographic  Service  Message  is  denoted  by  the  field  tag,  "CSM”. 

3)  The  contents  of  each  message  shall  begin  with  an  open  parenthesis  "("  and  end  with  a  close 
parenthesis  ")". 

4)  Field  tags  shall  be  separated  from  field  contents  by  a  solidus  7". 

5)  Fields  shall  be  separated  by  a  space  (J>). 

*6)  For  illustration,  plaintext  fields  are  represented  by  "ppp";  fields  containing  output  of  the 
GSF  are  represented  by  ”ffT. 

7)  It  is  the  responsibility  of  the  implementor  to  ensure  that  no  delimiters  (e.g.,  "b"  and  ".") 
appear  in  the  user  defmed  fields  (e.g.,  ORG,  RCV). 

*8)  ORG  and  RCV  refer  to  the  two  principals  involved  in  the  authentication  exchange.  For 
each  token,  ORG  and  RCV  are  the  sender  and  recipient,  respectively,  of  a  CSM. 

*9)  For  field  tags  indicating  a  certificate  (e.g.,  CRA,  CRB),  if  no  certificate  is  present,  the  field 
contents  shall  consist  only  of  a  space,  (i>). 

C.23  Basic  Functions 

*1)  The  Combine  Function: 

The  Combine  Function  combines  multiple  input  values.  For  purposes  of  this  appendix,  the 
Combine  Function  is  defined  to  equal  the  concatenation  of  the  input  values,  in  the  order 
that  they  are  listed  within  this  function.  A  solidus  7  shall  be  used  to  separate  the 
concatenated  fields.  In  Section  C.2.4  below,  the  Combine  Function  is  of  the  following 
form: 

Combine (  RCV , ORG , TVB , TVA  ) 


For  example,  if  RCV=alice,  ORG=bob,  TVB=abcdef  01,  TVa=23456789.  then  the 
result  of  die  combine  function  would  equal: 

alice/bob/abcdef 01/23456789 


•2)  The  Crypto  Function: 

The  Crypto  Function  cryptographically  transforms  the  input  DATA  (e.g.,  the  resuli  of  the 
Combine  Function),  using  the  CSM  sender's  (ORG)  private  key,  KPR1.  For  purposes  of 
this  appendix,  die  Crypto  Function  shall  use  a  FIPS  approved  digital  signature  algorithm 
(e.g.,  die  Digital  Signature  Algorithm  specified  in  FIPS  PUB  186)  to  generate  a  digital 
signature.  In  Section  C.2.4  below,  die  Crypto  Function  is  of  the  following  form: 

Crypto  (  KPRX , DATA  ) 

where  DATA  equals  die  result  of  the  Combine  Function  in  (1)  above. 

*3)  The  Select  Function: 

The  Select  Function  selects  and  returns  all  or  part  of  the  data  from  INPUT  (e.g..  the  result 
of  the  Crypto  Function),  facilitating  the  compression  of  messages.  For  purposes  of  this 
appendix,  die  Select  Function  will  select  ad  n  bits  of  INPUT.  In  Section  C.2.4  below,  the 
Select  Function  is  of  die  following  form: 

Select  (  INPUT  ) 

where  INPUT  equals  the  result  of  the  Crypto  Function  in  (2)  above 

*4)  The  General  Security  Function  (GSF),  is  used  to  authenticate  one  entity  to  another.  In 
Section  C.2.4  below,  the  GSF  is  formed  by  composing  the  previously  described  functions 
as  follows: 

GSF (  PRI , RCV , ORG , TVB , TVA  )  = 

Select (  Crypto (  KPRI , Combine (  RCV , ORG , TVB , TVA  )  )  ) 

C.2.4  Message  Formats 

In  each  of  the  messages  described  below,  the  message  class  tag  (MCL)  and  the  field  value  which 
follows  are  considered  to  be  a  TokenID.  In  MessageAB  and  MessageBA2,  each  included 
certificate  should  have  a  predefined  format,  which  is  left  to  the  implementor  to  define.  The 
message  formats  for  entity  authentication  tokens,  based  on  modified  ANSI  X9.26  specifications, 
are  as  follows: 
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TokenBA,: 


In  both  the  unilateral  and  mutual  exchanges,  the  first  message  is  a  random 
challenge  sent  from  B  to  A.  The  message  (MessageBAl)  that  includes 
TokenBA,  ("RCW.JTVB/ppp")  is: 


MessageBAl  = 

CSM  (MCL/TTMfeRCV/pppfcORG/pppkTVB/pppk) 

TTM  TVP  Transmission  Message  indicator  (message  class) 

RCV  Identity  of  message  recipient,  entity  A 
ORG  Identity  of  message  sender,  entity  B 

TVB  Random  number,  in  hexadecimal  format,  generated  by  entity  B.  the 
message  sender 


TokenAB:  In  both  the  unilateral  and  mutual  exchanges,  the  second  token  is  a 

response  to  B's  random  challenge.  Also  included  in  the  token  is  a 
random  number  generated  by  A.  The  message  (MessageAB)  that 
includes  TokenAB  ("RCV/...GSA/ffT)  is: 


MessageAB  = 

CSM  (MCL/ SMAfeRCV/pppbORG/pppbTVB/pppbTVA/pppbGSA/f f fbCRA/pppb) 

SMA  Entity  A's  Sign-on  Message  indicator  (message  class) 

RCV  Identity  of  message  recipient,  entity  B 
ORG  Identity  of  message  sender,  entity  A 

TVB  Random  number,  m  hexadecimal  format,  generated  by  entity  B,  the 
message  recipient 

TV  A  Random  number,  in  hexadecimal  format,  generated  by  entity  A,  the 
message  sender 

GSA  The  output  of  the  GSF  generated  by  entity  A. 

CRA  Entity  A's  public  key  certificate  (optional). 


TokenBA 2:  In  the  mutual  authentication  exchange,  a  third  message  is  sent,  which 

includes  B's  response  to  A's  random  challenge.  The  message 
(MessageBA2)  that  includes  TokenBA2  ("RCV/...GSB/ffT)  is: 


-  MessageBAl  = 

~  CSM ( MCL / SMBfeRCV / pppbORG / pppbTVB / pppbTVA / pppbG S  B / f  f  f bCRB / pppb ) 

SMB  Entity  B’s  Sign-on  Message  indicator  (message  class) 

RCV  Identity  of  message  recipient,  entity  A 
ORG  Identity  of  message  sender,  entity  B 


TVB  Random  number,  in  hexadecimal  format,  generated  bv  enmv  B  the 
message  sender 

TV  A  Random  number,  in  hexadecimal  formal,  generated  bv  enntv  a  the 
message  recipient 

GSB  The  output  of  the  GSF  generated  by  entity  B. 

GIB  Entity  B's  public  key  certificate  (optional). 


Appendix  D 

Example  Entity  Authentication  Exchange  Using  Base64  Encoding 


* 


This  appendix  is  provided  for  informational  purposes  only,  and  is  nor  pan  of  this  standard  The 
purpose  of  this  appendix  is  to  provide  implementors  of  this  standard  with  an  optional  method  for 
encoding  authentication  tokens.  The  method  described  below  for  encoding  formatted  tokens  is 
Base64  Content-Transfer-Encoding,  defined  in  Internet  RFC  1521,  MIME  (Multipurpose  internet 
Mail  Extensions)  Part  One  [15].  By  converting  data  to  ASCII  characters,  this  encoding  method 
allows  authentication  tokens  to  be  exchanged  over  unstructured,  non-binary  channels.  Note  that 
this  encoding  method  is  independent  of  die  format  of  the  authentication  tokens.  For  example. 
ASN.  1  /DER-encodcd  tokens  from  Appendices  A  and  B  might  also  be  base64-encoded.  depending 
on  die  transmission  channel's  ability  to  handle  binary  data.  Also,  there  exist  other,  similar 
encoding  schemes  that  may  provide  more  suitable  alternatives  for  a  particular  implementation. 
Section  D.5  will  present  an  example  of  using  base64  encoding  with  authentication  tokens 
described  in  Appendix  C,  even  though  they  are  already  formatted  using  only  ASCII  characters. 

D.l  Background 

When  authentication  is  conducted  within  a  security  services  protocol,  the  protocol  definition 
generally  specifies  where  the  authentication  information  is  located  and  how  it  is  represented. 
Once  the  authentication  information  is  formatted,  it  may  then  have  to  be  encoded  in  a  binary 
form.  If  the  channel  being  used  to  transmit  the  authentication  information  is  incapable  of 
handling  binary  data,  one  possible  solution  is  to  further  encode  the  data  using  base64  encoding 
as  defined  in  [15]. 

Regardless  of  the  encoding  method  used  (prior  to  performing  base64  encoding),  a  formatted 
authentication  message  will  be  referred  to  in  this  appendix  as  a  "transfer  string",  which  is  simply 
a  sequence  of  octets  with  known  length.  The  method  for  encoding  the  transfer  string  is 
independent  of  the  method  used  to  format  the  transfer  string;  however,  this  appendix  describes 
the  use  of  Base64  Content-Transfer-Encoding  [15]. 

Protocols  which  explicitly  support  security  services  are  able  to  carry  authentication  transfer 
strings  as-is.  However,  channels  which  have  no  protocol  support  for  security  services  may  also 
require  strong  authentication.  In  such  cases  the  authentication  information  is  carried  "in-band" 
as  part  of  the  normal  user  data.  This  presents  two  potential  problems:  the  authentication  data 
does  not  necessarily  appear  at  a  fixed  location,  and  the  channel  may  not  be  able  to  pass  arbitrary 
binary  information.  The  format  specified  in  this  appendix  addresses  both  problems. 

•  Tokens  begin  with  a  fixed  label  (token  identifier);  receivers  can  scan  an  incoming  data 
stream  for  labels  to  locate  potential  authentication  tokens. 

•  The  token  data  is  convened  to  a  text  representation  designed  to  pass  through  most  channels 
without  difficulty. 
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DJ  Base64  Content-Transfer-Encoding 

Assuming  that  a  transfer  string  has  been  generated  for  a  an  authentication  token,  the  encoding 
of  that  tnlfgn  must  take  place  before  including  it  in  an  "in-band"  transmission.  The  transfer  suing 
may  be  convened  to  a  base64  string  according  to  the  procedure  defined  in  internet  RFC  1521. 
The  following  description  is  adapted  from  [15],  Section  52: 

The  Base64  Content-Transfer-Encoding  is  designed  to  represent  arbitrary  sequences  of 
octets  in  a  form  that  need  not  be  humanly  readable.  The  encoding  and  decoding  algorithms 
are  simple,  but  die  encoded  data  are  consistently  only  about  33  percent  larger  than  the 
unencoded  data.  ...  A  65-character  subset  of  US-ASCQ  is  used,  enabling  6  bits  to  be 
represented  per  printable  character.  (The  extra  65th  character,  “=’\  is  used  to  signify  a 
special  processing  function.). . . . 

The  encoding  process  represents  24-bit  groups  of  input  bits  as  output  strings  of  [four] 
encoded  characters.  Proceeding  from  left  to  right,  a  24-bit  input  group  is  formed  by 
concatenating  [three]  8-bit  input  groups.  These  24  bits  are  then  treated  as  [four] 
concatenated  6-bit  groups,  each  of  which  is  translated  into  a  single  digit  in  the  base64 
alphabet.  When  encoding  a  bit  stream  via  the  base64  encoding,  the  bit  stream  must  be 
presumed  to  be  ordered  with  the  most-significant-bit  first  That  is,  the  first  bit  in  the  stream 
will  be  die  high-order  bit  in  the  first  byte,  and  the  eighth  bit  will  be  the  low-order  bit  in  the 
first  byte,  and  so  on. 


Table  II:  The  Base64  Alphabet 


Value 

Encoding 

Value 

Encoding 

Value 

Encoding 

Value 

Encoding 

0 

A 

17 

R 

34 

i 

51 

z 

1 

B 

18 

S 

35 

j 

52 

0 

2 

C 

19 

T 

36 

k 

53 

1 

3 

D 

20 

U 

37 

1 

54 

2 

4 

£ 

21 

V 

38 

m 

55 

3 

5 

F 

22 

w 

39 

n 

56 

4 

6 

G 

23 

X 

40 

0 

57 

5 

7 

H 

24 

Y 

41 

P 

58 

6 

8 

I 

25 

z 

42 

q 

59 

7 

9 

J 

26 

a 

43 

r 

60 

8 

10 

K 

27 

b 

44 

s 

61 

9 

11 

L 

28 

c 

45 

t 

62 

+ 

12 

M 

29 

d 

46 

u 

63 

/ 

13 

N 

30 

e 

47 

V 

14 

0 

31 

f 

48 

w 

(pad) 

= 

15 

P 

32 

g 

49 

X 

16 

Q 

33 

h 

50 

y 

Each  6-bit  group  is  used  as  an  index  into  an  array  of  64  printable  characters.  The  character 
referenced  by  the  index  is  placed  in  the  output  stnng.  These  characters,  identified  m  (Tabie 
U],  are  selected  so  as  to  be  universally  representable.  . . . 

The  output  stream  (encoded  bytes)  must  be  represented  in  lines  of  no  more  than  76 
characters  each.  All  line  breaks  or  other  characters  not  found  in  [Table  U]  must  be  ignored 
by  decoding  software,  in  base64  data,  characters  other  than  those  in  [Table  U].  line  breaks, 
and  other  white  space  probably  indicate  a  transmission  error,  about  which  a  warning 
message  or  even  a  message  rejection  might  be  appropriate  under  some  circumstances. 

Special  processing  is  performed  if  fewer  than  24  bits  are  available  at  the  end  of  the  data 
being  encoded.  A  full  encoding  [unit]  is  always  completed  at  the  end  of  a  body.  When 
fewer  than  24  input  bits  are  available  in  an  input  group,  zero  bits  are  added  (on  the  nght) 
to  form  an  integral  number  of  6-bit  groups.  Padding  at  the  end  of  the  data  is  performed 
using  the  •=*  character.  Since  all  base64  input  is  an  integral  number  of  octets,  only  the 
following  cases  can  arise:  (1)  die  final  [unit]  of  encoding  input  is  an  integral  multiple  of 
24  bits;  here,  die  final  unit  of  encoded  output  will  be  an  integral  multiple  of  [four] 
characters  with  no  “=”  paHHmg  (2)  the  final  [unit]  of  encoding  input  is  exactly  8  bits;  here, 
the  final  unit  of  encoded  output  will  be  two  characters  followed  by  two  4 padding 
characters,  or  (3)  die  final  [unit]  of  encoding  input  is  exactly  16  bits;  here,  the  final  unit 
of  encoded  output  will  be  three  characters  followed  by  one  44=”  padding  character.  [15] 


D 3  Format  of  In-Band  Authentication  Messages 

Once  a  token's  transfer  string  has  been  base64-encoded,  it  can  then  be  formatted  into  a  message 
of  the  form: 

Label44 :  ,Tbase64- string44:” 

The  label  identifies  the  type  of  token  being  sent,  and  may  be  considered  to  be  the  TokenID  (or 
part  of  the  TokenID)  specified  in  the  FIPS  authentication  protocols.  Labels  have  been  given  the 
"FIPSEA"  prefix,  which  stands  for  "FIPS  Entity  Authentication": 

FIPSEAJBAl  -Initial  token  from  B  to  A  in  both  Unilateral  and  Mutual  exchanges. 
FIPSEA_AB  -Response  token  from  A  to  B  in  both  Unilateral  and  Mutual  exchanges. 

FIPSEAJBA2  -Response  token  from  B  to  A  in  the  Mutual  exchange. 

The  base64- string  is  delimited  by  colon  (:)  characters  to  allow  its  extent  to  be  determined 
unambiguously.  The  initial  colon  must  immediately  follow  the  Label  with  no  intervening 
whitespace  or  other  characters.  The  base64-stnng  may  include  line  breaks  or  other  whitespace, 
as  specified  in  Section  D.2. 
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D.4  Error  detection 

This  formatting  method  does  not  explicitly  include  any  error  control  mechanisms  although  it 
does  allow  some  sanity  checks  to  be  applied  to  received  data.  Because  they  are  used  only  at  the 
end  of  the  data,  the  occurrence  of  any  1=1  or characters  may  be  taken  as  evidence  that  the  end 
of  the  dnw>  has  been  readied  without  truncation  in  transit  The  occurrence  of  any  non-whitespace 
characters  between  the  1=1  characters  (if  any)  and  the  trailing indicates  an  error  in  transit.  Am 
errors  in  the  label/imtial  colon  and  any  non-base64  character  before  die  final  colon  should  cause 
die  token  to  be  treated  as  corrupt 

Explicit  error  control  coding  (to  enable  more  extensive  error  detection  or  collection)  can  be 
applied  as  part  of  the  encoding  method,  or  as  a  separate  step  after  encoding  but  before 
formatting.  - 


BJ  Example 

For  purposes  of  example,  the  authentication  messages  from  Appendix  C  will  be  base64- encoded. 
In  many  cases,  those  messages  will  not  need  to  be  encoded,  since  they  are  likely  to  be  in  ASCII- 
only  format  However,  this  example  will  be  used  to  demonstrate  both  the  ANSI  X9.26-based 
formatting  and  die  base64  encoding  The  digital  signatures  in  MessageAB  and  MessageBA2  will 
be  generated  using  the  Digital  Signature  Algorithm  specified  in  FIPS  PUB  186.  and  no 
certificates  will  be  included.  The  base64  encoding  is  generated  beginning  with  the  characters 
"CSM"  and  ending  with  the  close  parenthesis  ")"  for  each  message. 


Mutual  entity  authentication: 


Entity  A's  ID= 

Entity  A's  TVP= 

Entity  A's  private  key  (hex)= 


alice 

d6f 47bc433299436 

374b8a09ae40ced4d9510256bf 7f 3262679e3b3f 


Entity  B's  ID= 

Entity  B's  TVP= 

Entity  B's  private  key  (hex): 


bob 

e69dfb21f f d051a3 

39  03  82c6aa97  8875ec7f 3160bc9d675e430da255 


MessageBAl  = 

CSM (MCL/SMA  RCV/alice  ORG/bob  TVB/e69dfb21f fd051a3) 

Once  this  message  is  labeled  and  base64-encoded,  the  result  is: 

FIPSEA_BAl:QlNNKElDTC9TTUEgUtoJWL2F3aWNlIE9SRy9ib2IgVFZCL2U20WRmYjIxZmZkMD 

UxYTMp: 
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MessageAB  * 


CSM (MCL/SMA  RCV/bob  ORG/alice  TVB/e69dfb21f f d051a3  TVA/d6f47bci2329943- 
GSA/bl72f97910da3e5dde070c2af334eaa349063695938969d02882a8a7736C?  SeDS '  a"5  c 
cf 8£d33844c  CRA/  ) 

Once  this  message  is  labeled  and  base64-encoded,  die  result  is: 

FIPSEAl_AB  :  QlNNKElDTC9TTUEgUkNWL2  JvYiBPDkcvYWxpY2UgVFZCL2D20WRmY3  IxZmZkMDU 
xYTMgVFZBI^Q2ZjQ3YnMOMzMyOTkOMzYgRlNBL2IxNzJmOTc5MTBkYTNlNWRkZTA3MGMyYWY:: 
MzRlYWEzNDkwNjM20T05Mzg5Nj  lkMDI40DJh0GE3NzM2MD£lZTA4MWEz0GNxn0GZkMzM4NDR;;  : 
ENSQS8gK0*»: 


MessageBA2  ■ 

CSM (MCL/SMB  RCV/alice  ORG/bob  TVB/e69dfb21ff d051a3  TVA/d6f 47be433299436 
GSB/c26ac822a93d5c349962dla78a229d27abfea415b934b2604e6facce2c233afc59be6 
be6a9e262£5  CRB/  ) 


Once  this  message  is  labeled  and  base64-encoded,  die  result  is: 

FIPSEA^_BA2 :01NNKElDTC9TTlJIgD)cNWL2F8aWNlIE9SRy9ib2IgVFZCL2D2OWRinYj  IxZmZkMD 
UxY7MgVFZBL2Q2ZjQ3YmMOMzMyOTkOMzYgRlNCL2MyNmFjODIyYTkzZDVjMzQ50TYyZDFhNzh 
hMj  I5ZDI3YWJmZWEOMTViOTMOYj  I2MDRlNmZbY2NlMmMyMzNhZmM10WJlNmJlNmE5ZTI2MmYl 
IENSQi8gKQ“: 


Of 


0 


o  ' 
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